System and methods for verifying that one or more directives that direct transport of a second end user does not conflict with one or more obligations to transport a first end user

ABSTRACT

Computationally implemented methods and systems that are designed for receiving one or more first directives that direct a transportation vehicle unit to transport a first end user; receiving, while the transportation vehicle unit is en route to or is transporting the first end user, one or more second directives that direct the transportation vehicle unit to transport a second end user while transporting the first end user, the transportation vehicle unit having been determined to be able to accommodate transport of the second end user while transporting the first end user; and verifying that compliance with the one or more second directives will not conflict with one or more obligations to transport the first end user by the transportation vehicle unit. In addition to the foregoing, other aspects are described in the claims, drawings, and text.

CROSS-REFERENCE TO RELATED APPLICATIONS

For purposes of the USPTO extra-statutory requirements, the presentapplication claims benefit of priority of U.S. Provisional PatentApplication No. 61/989,394 titled RIDESHARING SCENARIOS, naming RichardT. Lord and Robert W. Lord as inventors, filed May 6, 2014, which wasfiled within the twelve months preceding the filing date of the presentapplication or is an application of which a currently co-pendingapplication is entitled to the benefit of the filing date, and each ofthe below (a)-(j) claim the benefit of this provisional application. Theentire contents of U.S. Provisional Patent Application No. 61/989,394 isincorporate by reference herein.

The present application is a continuation of application Ser. No.15/588,502 filed May 5, 2017, which is (a) a continuation-in-part ofU.S. patent application Ser. No. 14/318,182, entitled METHODS, SYSTEMS,AND DEVICES FOR PROVIDING TRANSPORTATION SERVICES, naming Richard T.Lord, Robert W. Lord, Nathan P. Myhrvold, and Clarence T. Tegreene, asinventors, filed 27 Jun. 2014, (b) a continuation-in-part of U.S. patentapplication Ser. No. 14/329,451, entitled SYSTEMS AND METHODS FOR TRAVELPLANNING THAT CALLS FOR AT LEAST ONE TRANSPORTATION VEHICLE UNIT, namingRichard T. Lord, Robert W. Lord, Nathan P. Myhrvold, and Clarence T.Tegreene, as inventors, filed 11 Jul. 2014, and which is a continuationof U.S. patent application Ser. No. 14/328,002, entitled SYSTEMS ANDMETHODS FOR TRAVEL PLANNING THAT CALLS FOR AT LEAST ONE TRANSPORTATIONVEHICLE UNIT, naming Richard T. Lord, Robert W. Lord, Nathan P.Myhrvold, and Clarence T. Tegreene, as inventors, filed 10 Jul. 2014,(c) a continuation-in-part of U.S. patent application Ser. No.14/456,627, entitled SYSTEM AND METHODS FOR PROVIDING AT LEAST A PORTIONOF A TRAVEL PLAN THAT CALLS FOR AT LEAST ONE TRANSPORTATION VEHICLEUNIT, naming Richard T. Lord, Robert W. Lord, Nathan P. Myhrvold, andClarence T. Tegreene, as inventors, filed 11 Aug. 2014, and which is acontinuation of U.S. patent application Ser. No. 14/455,534, entitledSYSTEM AND METHODS FOR PROVIDING AT LEAST A PORTION OF A TRAVEL PLANTHAT CALLS FOR AT LEAST ONE TRANSPORTATION VEHICLE UNIT, naming RichardT. Lord, Robert W. Lord, Nathan P. Myhrvold, and Clarence T. Tegreene,as inventors, filed 8 Aug. 2014, (d) a continuation-in-part of U.S.patent application Ser. No. 14/476,042, entitled SYSTEM AND METHODS FORIDENTIFYING ONE OR MORE TRANSPORTATION VEHICLE UNITS WITH OR WITHOUTPACKAGE DELIVERY OBLIGATION FOR TRANSPORTING ONE OR MORE END USERS,naming Richard T. Lord, Robert W. Lord, Nathan P. Myhrvold, and ClarenceT. Tegreene, as inventors, filed 3 Sep. 2014, and which is acontinuation of U.S. patent application Ser. No. 14/474,587, entitledSYSTEM AND METHODS FOR IDENTIFYING ONE OR MORE TRANSPORTATION VEHICLEUNITS WITH OR WITHOUT PACKAGE DELIVERY OBLIGATION FOR TRANSPORTING ONEOR MORE END USERS, naming Richard T. Lord, Robert W. Lord, Nathan P.Myhrvold, and Clarence T. Tegreene, as inventors, filed 2 Sep. 2014, (e)a continuation-in-part of U.S. patent application Ser. No. 14/511,706,entitled SYSTEM AND METHODS FOR DIRECTING ONE OR MORE TRANSPORTATIONVEHICLE UNITS TO TRANSPORT ONE OR MORE END USERS, naming Richard T.Lord, Robert W. Lord, Nathan P. Myhrvold, and Clarence T. Tegreene, asinventors, filed 10 Oct. 2014, and which is a continuation of U.S.patent application Ser. No. 14/510,383, entitled SYSTEM AND METHODS FORDIRECTING ONE OR MORE TRANSPORTATION VEHICLE UNITS TO TRANSPORT ONE ORMORE END USERS, naming Richard T. Lord, Robert W. Lord, Nathan P.Myhrvold, and Clarence T. Tegreene, as inventors, filed 9 Oct. 2014, (f)a continuation-in-part of U.S. patent application Ser. No. 14/537,313,entitled SYSTEM AND METHODS FOR VERIFYING THAT ONE OR MORE END USERTRANSPORT DIRECTIVES DO NOT CONFLICT WITH ONE OR MORE PACKAGE DELIVERYDIRECTIVES, naming Richard T. Lord, Robert W. Lord, Nathan P. Myhrvold,and Clarence T. Tegreene, as inventors, filed 10 Nov. 2014, and which isa continuation of U.S. patent application Ser. No. 14/536,967, entitledSYSTEM AND METHODS FOR VERIFYING THAT ONE OR MORE END USER TRANSPORTDIRECTIVES DO NOT CONFLICT WITH ONE OR MORE PACKAGE DELIVERY DIRECTIVES,naming Richard T. Lord, Robert W. Lord, Nathan P. Myhrvold, and ClarenceT. Tegreene, as inventors, filed 10 Nov. 2014, (g) acontinuation-in-part of U.S. patent application Ser. No. 14/564,358,entitled SYSTEM AND METHODS FOR FACILITATING REAL-TIME CARPOOLING,naming Richard T. Lord, Robert W. Lord, Nathan P. Myhrvold, and ClarenceT. Tegreene, as inventors, filed 9 Dec. 2014, and which is acontinuation of U.S. patent application Ser. No. 14/563,134, entitledSYSTEM AND METHODS FOR FACILITATING REAL-TIME CARPOOLING, naming RichardT. Lord, Robert W. Lord, Nathan P. Myhrvold, and Clarence T. Tegreene,as inventors, filed 8 Dec. 2014, (h) a continuation-in-part of U.S.patent application Ser. No. 14/597,631, entitled REAL-TIME CARPOOLINGCOORDINATING SYSTEM AND METHODS, naming Richard T. Lord, Robert W. Lord,Nathan P. Myhrvold, and Clarence T. Tegreene, as inventors, filed 15Jan. 2015, and which is a continuation of U.S. patent application Ser.No. 14/596,904, entitled REAL-TIME CARPOOLING COORDINATING SYSTEM ANDMETHODS, naming Richard T. Lord, Robert W. Lord, Nathan P. Myhrvold, andClarence T. Tegreene, as inventors, filed 14 Jan. 2015, (i) acontinuation of U.S. patent application Ser. No. 14/619,812, entitledSYSTEM AND METHODS FOR VERIFYING THAT ONE OR MORE DIRECTIVES THAT DIRECTTRANSPORT OF A SECOND END USER DOES NOT CONFLICT WITH ONE OR MOREOBLIGATIONS TO TRANSPORT A FIRST END USER, naming Richard T. Lord,Robert W. Lord, Nathan P. Myhrvold, and Clarence T. Tegreene, asinventors, filed 11 Feb. 2015, (j) a continuation of U.S. patentapplication Ser. No. 14/621,151, entitled SYSTEM AND METHODS FORVERIFYING THAT ONE OR MORE DIRECTIVES THAT DIRECT TRANSPORT OF A SECONDEND USER DOES NOT CONFLICT WITH ONE OR MORE OBLIGATIONS TO TRANSPORT AFIRST END USER, naming Richard T. Lord, Robert W. Lord, Nathan P.Myhrvold, and Clarence T. Tegreene, as inventors, filed 12 Feb. 2015,the entire contents of each of the above-referenced patents and patentapplications are incorporated herein by reference.

The United States Patent Office (USPTO) has published a notice to theeffect that the USPTO's computer programs require that patent applicantsreference both a serial number and indicate whether an application is acontinuation, continuation-in-part, or divisional of a parentapplication. Stephen G. Kunin, Benefit of Prior-Filed Application, USPTOOfficial Gazette Mar. 18, 2003. The USPTO further has provided forms forthe Application Data Sheet which allow automatic loading ofbibliographic data but which require identification of each applicationas a continuation, continuation-in-part, or divisional of a parentapplication. The present Applicant Entity (hereinafter “Applicant”) hasprovided above a specific reference to the application(s) from whichpriority is being claimed as recited by statute. Applicant understandsthat the statute is unambiguous in its specific reference language anddoes not require either a serial number or any characterization, such as“continuation” or “continuation-in-part,” for claiming priority to U.S.patent applications. Notwithstanding the foregoing, Applicantunderstands that the USPTO's computer programs have certain data entryrequirements, and hence Applicant has provided designation(s) of arelationship between the present application and its parentapplication(s) as set forth above and in any ADS filed in thisapplication, but expressly points out that such designation(s) are notto be construed in any way as any type of commentary and/or admission asto whether or not the present application contains any new matter inaddition to the matter of its parent application(s).

If the listings of applications provided above are inconsistent with thelistings provided via an ADS, it is the intent of the Applicant to claimpriority to each application that appears in the Priority Applicationssection of the ADS and to each application that appears in the PriorityApplications section of this application.

All subject matter of the Priority Applications and the RelatedApplications and of any and all parent, grandparent, great-grandparent,etc. applications of the Priority Applications and the RelatedApplications, including any priority claims, is incorporated herein byreference to the extent such subject matter is not inconsistentherewith.

SUMMARY

In one or more various aspects, a method includes, but is not limitedto, receiving one or more first directives that direct a transportationvehicle unit to transport a first end user, receiving, while thetransportation vehicle unit is en route to or is transporting the firstend user, one or more second directives that direct the transportationvehicle unit to transport a second end user while transporting the firstend user, the transportation vehicle unit having been determined to beable to accommodate transport of the second end user while transportingthe first end user; and verifying that compliance with the one or moresecond directives will not conflict with one or more obligations totransport the first end user by the transportation vehicle unit. Invarious implementations, at least one of the above operations isperformed by a machine or an article of manufacture. In addition to theforegoing, other method aspects are described in the claims, drawings,and text forming a part of the disclosure set forth herein.

In one or more various aspects, one or more related systems may beimplemented in machines, compositions of matter, or manufactures ofsystems, limited to patentable subject matter under 35 U.S.C. 101. Theone or more related systems may include, but are not limited to,circuitry and/or programming for effecting the herein-referenced methodaspects. The circuitry and/or programming may be virtually anycombination of hardware, software, and/or firmware configured to effectthe herein-referenced method aspects depending upon the design choicesof the system designer, and limited to patentable subject matter under35 USC 101.

In one or more various aspects, a system includes, but is not limitedto, means for receiving one or more first directives that direct atransportation vehicle unit to transport a first end user, means forreceiving, while the transportation vehicle unit is en route to or istransporting the first end user, one or more second directives thatdirect the transportation vehicle unit to transport a second end userwhile transporting the first end user, the transportation vehicle unithaving been determined to be able to accommodate transport of the secondend user while transporting the first end user; and means for verifyingthat compliance with the one or more second directives will not conflictwith one or more obligations to transport the first end user by thetransportation vehicle unit. In addition to the foregoing, other systemaspects are described in the claims, drawings, and text forming a partof the disclosure set forth herein.

In one or more various aspects, a system includes, but is not limitedto, circuitry for receiving one or more first directives that direct atransportation vehicle unit to transport a first end user, circuitry forreceiving, while the transportation vehicle unit is en route to or istransporting the first end user, one or more second directives thatdirect the transportation vehicle unit to transport a second end userwhile transporting the first end user, the transportation vehicle unithaving been determined to be able to accommodate transport of the secondend user while transporting the first end user; and circuitry forverifying that compliance with the one or more second directives willnot conflict with one or more obligations to transport the first enduser by the transportation vehicle unit. In addition to the foregoing,other system aspects are described in the claims, drawings, and textforming a part of the disclosure set forth herein.

In one or more various aspects, a computer program product, comprising asignal bearing non-transitory storage medium, bearing one or moreinstructions including, but not limited to, receiving one or more firstdirectives that direct a transportation vehicle unit to transport afirst end user, receiving, while the transportation vehicle unit is enroute to or is transporting the first end user, one or more seconddirectives that direct the transportation vehicle unit to transport asecond end user while transporting the first end user, thetransportation vehicle unit having been determined to be able toaccommodate transport of the second end user while transporting thefirst end user, and verifying that compliance with the one or moresecond directives will not conflict with one or more obligations totransport the first end user by the transportation vehicle unit. Inaddition to the foregoing, other computer program product aspects aredescribed in the claims, drawings, and text forming a part of thedisclosure set forth herein.

In one or more various aspects, a system includes, but is not limitedto, a directive receiving module configured to receive, while atransportation vehicle unit is en route to or is transporting a firstend user, one or more directives that direct the transportation vehicleunit to transport a second end user while transporting the first enduser, the transportation vehicle unit having been determined to be ableto accommodate transport of the second end user while transporting thefirst end user; a non-conflict confirming module configured to confirmthat compliance with the one or more second directives will not conflictwith one or more obligations to transport the first end user by thetransportation vehicle unit; a memory, and one or more processors.

In one or more various aspects, a system includes, but is not limitedto, circuitry for receiving, while a transportation vehicle unit is enroute to or is transporting a first end user, one or more directivesthat direct the transportation vehicle unit to transport a second enduser while transporting the first end user, the transportation vehicleunit having been determined to be able to accommodate transport of thesecond end user while transporting the first end user; and circuitry forconfirming that compliance with the one or more second directives willnot conflict with one or more obligations to transport the first enduser by the transportation vehicle unit.

In addition to the foregoing, various other method and/or system and/orprogram product aspects are set forth and described in the teachingssuch as text (e.g., claims and/or detailed description) and/or drawingsof the present disclosure.

The foregoing is a summary and thus may contain simplifications,generalizations, inclusions, and/or omissions of detail; consequently,those skilled in the art will appreciate that the summary isillustrative only and is NOT intended to be in any way limiting. Otheraspects, features, and advantages of the devices and/or processes and/orother subject matter described herein will become apparent by referenceto the detailed description, the corresponding drawings, and/or in theteachings set forth herein.

BRIEF DESCRIPTION OF THE FIGURES

For a more complete understanding of embodiments, reference now is madeto the following descriptions taken in connection with the accompanyingdrawings. The use of the same symbols in different drawings typicallyindicates similar or identical items, unless context dictates otherwise.The illustrative embodiments described in the detailed description,drawings, and claims are not meant to be limiting. Other embodiments maybe utilized, and other changes may be made, without departing from thespirit or scope of the subject matter presented here.

FIG. 1 illustrates a transport computing device 10* operating in anexemplary environment

FIG. 2A shows a high-level block diagram of a particular implementationof the transport computing device 10* of FIG. 1 (illustrated astransport computing device 10′).

FIG. 2B shows another high-level block diagram of another implementationof the transport computing device 10* of FIG. 1 (illustrated astransport computing device 10″).

FIG. 3A shows another perspective of the directive receiving module 202*of FIGS. 2A and 2B (e.g., the directive receiving module 202′ of FIG. 2Aor the directive receiving module 202″ of FIG. 2B) in accordance withvarious embodiments.

FIG. 3B shows another perspective of the non-conflict confirming module204* of FIGS. 2A and 2B (e.g., the non-conflict confirming module 204′of FIG. 2A or the non-conflict confirming module 204″ of FIG. 2B) inaccordance with various embodiments.

FIG. 3C shows another perspective of the instructive directivepresenting module 208* of FIGS. 2A and 2B (e.g., the instructivedirective presenting module 208′ of FIG. 2A or the instructive directivepresenting module 208″ of FIG. 2B) in accordance with variousembodiments.

FIG. 4A illustrates an exemplary route that an example transportationvehicle unit 20 of FIG. 1 may use in order to transport carpoolingpassengers.

FIG. 4B illustrates another exemplary route that the exampletransportation vehicle unit 20 of FIG. 1 may use in order to transportcarpooling passengers.

FIG. 4C illustrates another exemplary route that the exampletransportation vehicle unit 20 of FIG. 1 may use in order to transportcarpooling passengers.

FIG. 4D illustrates another exemplary route that the exampletransportation vehicle unit 20 of FIG. 1 may use in order to transportcarpooling passengers.

FIG. 4E illustrates an exemplary robotic driver system 450 that includesthe transport computing device 10* of FIG. 2A or 2B.

FIG. 5 is a high-level logic flowchart of a process, e.g., operationalflow 500, according to some embodiments.

FIG. 6A is a high-level logic flowchart of a process depicting alternateimplementations of the first directive receiving operation 502 of FIG.5.

FIG. 6B is a high-level logic flowchart of a process depicting alternateimplementations of the first directive receiving operation 502 of FIG.5.

FIG. 6C is a high-level logic flowchart of a process depicting alternateimplementations of the first directive receiving operation 502 of FIG.5.

FIG. 6D is a high-level logic flowchart of a process depicting alternateimplementations of the first directive receiving operation 502 of FIG.5.

FIG. 7A is a high-level logic flowchart of a process depicting alternateimplementations of the second directive receiving operation 504 of FIG.5.

FIG. 7B is a high-level logic flowchart of a process depicting alternateimplementations of the second directive receiving operation 504 of FIG.5.

FIG. 7C is a high-level logic flowchart of a process depicting alternateimplementations of the second directive receiving operation 504 of FIG.5.

FIG. 7D is a high-level logic flowchart of a process depicting alternateimplementations of the second directive receiving operation 504 of FIG.5.

FIG. 8A is a high-level logic flowchart of a process depicting alternateimplementations of the non-conflict verifying operation 506 of FIG. 5.

FIG. 8B is a high-level logic flowchart of a process depicting alternateimplementations of the non-conflict verifying operation 506 of FIG. 5.

FIG. 8C is a high-level logic flowchart of a process depicting alternateimplementations of the non-conflict verifying operation 506 of FIG. 5.

FIG. 8D is a high-level logic flowchart of a process depicting alternateimplementations of the non-conflict verifying operation 506 of FIG. 5.

FIG. 8E is a high-level logic flowchart of a process depicting alternateimplementations of the non-conflict verifying operation 506 of FIG. 5.

FIG. 8F is a high-level logic flowchart of a process depicting alternateimplementations of the non-conflict verifying operation 506 of FIG. 5.

FIG. 8G is a high-level logic flowchart of a process depicting alternateimplementations of the non-conflict verifying operation 506 of FIG. 5.

FIG. 9 is a high-level logic flowchart of another process, e.g.,operational flow 900, according to some embodiments.

FIG. 10 is a high-level logic flowchart of yet another process, e.g.,operational flow 1000, according to some embodiments.

FIG. 11 is a high-level logic flowchart of a process depicting alternateimplementations of the instructive directive presenting operation 1008of FIG. 10.

DETAILED DESCRIPTION

In the following detailed description, reference is made to theaccompanying drawings, which form a part hereof. In the drawings,similar symbols typically identify similar or identical components oritems, unless context dictates otherwise. The illustrative embodimentsdescribed in the detailed description, drawings, and claims are notmeant to be limiting. Other embodiments may be utilized, and otherchanges may be made, without departing from the spirit or scope of thesubject matter presented here.

Thus, in accordance with various embodiments, computationallyimplemented methods, systems, circuitry, articles of manufacture,ordered chains of matter, and computer program products are designed to,among other things, provide one or more wearable computing devices forthe environment illustrated in FIG. 1.

The claims, description, and drawings of this application may describeone or more of the instant technologies in operational/functionallanguage, for example as a set of operations to be performed by acomputer. Such operational/functional description in most instanceswould be understood by one skilled the art as specifically-configuredhardware (e.g., because a general purpose computer in effect becomes aspecial purpose computer once it is programmed to perform particularfunctions pursuant to instructions from program software).

Importantly, although the operational/functional descriptions describedherein are understandable by the human mind, they are not abstract ideasof the operations/functions divorced from computational implementationof those operations/functions. Rather, the operations/functionsrepresent a specification for the massively complex computationalmachines or other means. As discussed in detail below, theoperational/functional language must be read in its proper technologicalcontext, i.e., as concrete specifications for physical implementations.

The logical operations/functions described herein are a distillation ofmachine specifications or other physical mechanisms specified by theoperations/functions such that the otherwise inscrutable machinespecifications may be comprehensible to the human mind. The distillationalso allows one of skill in the art to adapt the operational/functionaldescription of the technology across many different specific vendors'hardware configurations or platforms, without being limited to specificvendors' hardware configurations or platforms.

Some of the present technical description (e.g., detailed description,drawings, claims, etc.) may be set forth in terms of logicaloperations/functions. As described in more detail in the followingparagraphs, these logical operations/functions are not representationsof abstract ideas, but rather representative of static or sequencedspecifications of various hardware elements. Differently stated, unlesscontext dictates otherwise, the logical operations/functions will beunderstood by those of skill in the art to be representative of staticor sequenced specifications of various hardware elements. This is truebecause tools available to one of skill in the art to implementtechnical disclosures set forth in operational/functional formats—toolsin the form of a high-level programming language (e.g., C, java, visualbasic, etc.), or tools in the form of Very high speed HardwareDescription Language (“VHDL,” which is a language that uses text todescribe logic circuits)—are generators of static or sequencedspecifications of various hardware configurations. This fact issometimes obscured by the broad term “software,” but, as shown by thefollowing explanation, those skilled in the art understand that what istermed “software” is a shorthand for a massively complexinterchaining/specification of ordered-matter elements. The term“ordered-matter elements” may refer to physical components ofcomputation, such as assemblies of electronic logic gates, molecularcomputing logic constituents, quantum computing mechanisms, etc.

For example, a high-level programming language is a programming languagewith strong abstraction, e.g., multiple levels of abstraction, from thedetails of the sequential organizations, states, inputs, outputs, etc.,of the machines that a high-level programming language actuallyspecifies. See, e.g., Wikipedia, High-level programming language,http://en.wikipedia.org/wiki/High-level_programming_language (as of Jun.5, 2012, 21:00 GMT). In order to facilitate human comprehension, in manyinstances, high-level programming languages resemble or even sharesymbols with natural languages. See, e.g., Wikipedia, Natural language,http://en.wikipedia.org/wiki/Natural_language (as of Jun. 5, 2012, 21:00GMT).

It has been argued that because high-level programming languages usestrong abstraction (e.g., that they may resemble or share symbols withnatural languages), they are therefore a “purely mental construct”(e.g., that “software”—a computer program or computer programming—issomehow an ineffable mental construct, because at a high level ofabstraction, it can be conceived and understood in the human mind). Thisargument has been used to characterize technical description in the formof functions/operations as somehow “abstract ideas.” In fact, intechnological arts (e.g., the information and communicationtechnologies) this is not true.

The fact that high-level programming languages use strong abstraction tofacilitate human understanding should not be taken as an indication thatwhat is expressed is an abstract idea. In fact, those skilled in the artunderstand that just the opposite is true. If a high-level programminglanguage is the tool used to implement a technical disclosure in theform of functions/operations, those skilled in the art will recognizethat, far from being abstract, imprecise, “fuzzy,” or “mental” in anysignificant semantic sense, such a tool is instead a nearincomprehensibly precise sequential specification of specificcomputational machines—the parts of which are built up byactivating/selecting such parts from typically more generalcomputational machines over time (e.g., clocked time). This fact issometimes obscured by the superficial similarities between high-levelprogramming languages and natural languages. These superficialsimilarities also may cause a glossing over of the fact that high-levelprogramming language implementations ultimately perform valuable work bycreating/controlling many different computational machines.

The many different computational machines that a high-level programminglanguage specifies are almost unimaginably complex. At base, thehardware used in the computational machines typically consists of sometype of ordered matter (e.g., traditional external linking devices(e.g., transistors), deoxyribonucleic acid (DNA), quantum devices,mechanical switches, optics, fluidics, pneumatics, optical devices(e.g., optical interference devices, molecules, etc.) that are arrangedto form logic gates. Logic gates are typically physical devices that maybe electrically, mechanically, chemically, or otherwise driven to changephysical state in order to create a physical reality of Boolean logic.

Logic gates may be arranged to form logic circuits, which are typicallyphysical devices that may be electrically, mechanically, chemically, orotherwise driven to create a physical reality of certain logicalfunctions. Types of logic circuits include such devices as multiplexers,registers, arithmetic logic units (ALUs), computer memory, etc., eachtype of which may be combined to form yet other types of physicaldevices, such as a central processing unit (CPU)—the best known of whichis the microprocessor. A modern microprocessor will often contain morethan one hundred million logic gates in its many logic circuits (andoften more than a billion transistors). See, e.g., Wikipedia, Logicgates, http://en.wikipedia.org/wiki/Logic gates (as of Jun. 5, 2012,21:03 GMT).

The logic circuits forming the microprocessor are arranged to provide amicroarchitecture that will carry out the instructions defined by thatmicroprocessor's defined Instruction Set Architecture. The InstructionSet Architecture is the part of the microprocessor architecture relatedto programming, including the native data types, instructions,registers, addressing modes, memory architecture, interrupt andexception handling, and external Input/Output. See, e.g., Wikipedia,Computer architecture,http://en.wikipedia.org/wiki/Computer_architecture (as of Jun. 5, 2012,21:03 GMT).

The Instruction Set Architecture includes a specification of the machinelanguage that can be used by programmers to use/control themicroprocessor. Since the machine language instructions are such thatthey may be executed directly by the microprocessor, typically theyconsist of strings of binary digits, or bits. For example, a typicalmachine language instruction might be many bits long (e.g., 32, 64, or128 bit strings are currently common). A typical machine languageinstruction might take the form “11110000101011110000111100111111” (a 32bit instruction).

It is significant here that, although the machine language instructionsare written as sequences of binary digits, in actuality those binarydigits specify physical reality. For example, if certain semiconductorsare used to make the operations of Boolean logic a physical reality, theapparently mathematical bits “1” and “0” in a machine languageinstruction actually constitute shorthand that specifies the applicationof specific voltages to specific wires. For example, in somesemiconductor technologies, the binary number “1” (e.g., logical “1”) ina machine language instruction specifies around +5 volts applied to aspecific “wire” (e.g., metallic traces on a printed circuit board) andthe binary number “0” (e.g., logical “0”) in a machine languageinstruction specifies around −5 volts applied to a specific “wire.” Inaddition to specifying voltages of the machines' configuration, suchmachine language instructions also select out and activate specificgroupings of logic gates from the millions of logic gates of the moregeneral machine. Thus, far from abstract mathematical expressions,machine language instruction programs, even though written as a stringof zeros and ones, specify many, many constructed physical machines orphysical machine states.

Machine language is typically incomprehensible by most humans (e.g., theabove example was just ONE instruction, and some personal computersexecute more than two billion instructions every second). See, e.g.,Wikipedia, Instructions per second,http://en.wikipedia.org/wiki/Instructions_per_second (as of Jun. 5,2012, 21:04 GMT). Thus, programs written in machine language—which maybe tens of millions of machine language instructions long—areincomprehensible. In view of this, early assembly languages weredeveloped that used mnemonic codes to refer to machine languageinstructions, rather than using the machine language instructions'numeric values directly (e.g., for performing a multiplicationoperation, programmers coded the abbreviation “mult,” which representsthe binary number “011000” in MIPS machine code). While assemblylanguages were initially a great aid to humans controlling themicroprocessors to perform work, in time the complexity of the work thatneeded to be done by the humans outstripped the ability of humans tocontrol the microprocessors using merely assembly languages.

At this point, it was noted that the same tasks needed to be done overand over, and the machine language necessary to do those repetitivetasks was the same. In view of this, compilers were created. A compileris a device that takes a statement that is more comprehensible to ahuman than either machine or assembly language, such as “add 2+2 andoutput the result,” and translates that human understandable statementinto a complicated, tedious, and immense machine language code (e.g.,millions of 32, 64, or 128 bit length strings). Compilers thus translatehigh-level programming language into machine language.

This compiled machine language, as described above, is then used as thetechnical specification which sequentially constructs and causes theinteroperation of many different computational machines such thathumanly useful, tangible, and concrete work is done. For example, asindicated above, such machine language—the compiled version of thehigher-level language—functions as a technical specification whichselects out hardware logic gates, specifies voltage levels, voltagetransition timings, etc., such that the humanly useful work isaccomplished by the hardware.

Thus, a functional/operational technical description, when viewed by oneof skill in the art, is far from an abstract idea. Rather, such afunctional/operational technical description, when understood throughthe tools available in the art such as those just described, is insteadunderstood to be a humanly understandable representation of a hardwarespecification, the complexity and specificity of which far exceeds thecomprehension of most any one human. With this in mind, those skilled inthe art will understand that any such operational/functional technicaldescriptions—in view of the disclosures herein and the knowledge ofthose skilled in the art—may be understood as operations made intophysical reality by (a) one or more interchained physical machines, (b)interchained logic gates configured to create one or more physicalmachine(s) representative of sequential/combinatorial logic(s), (c)interchained ordered matter making up logic gates (e.g., interchainedelectronic devices (e.g., transistors), DNA, quantum devices, mechanicalswitches, optics, fluidics, pneumatics, molecules, etc.) that createphysical reality representative of logic(s), or (d) virtually anycombination of the foregoing. Indeed, any physical object which has astable, measurable, and changeable state may be used to construct amachine based on the above technical description. Charles Babbage, forexample, constructed the first computer out of wood and powered bycranking a handle.

Thus, far from being understood as an abstract idea, those skilled inthe art will recognize a functional/operational technical description asa humanly-understandable representation of one or more almostunimaginably complex and time sequenced hardware instantiations. Thefact that functional/operational technical descriptions might lendthemselves readily to high-level computing languages (or high-levelblock diagrams for that matter) that share some words, structures,phrases, etc. with natural language simply cannot be taken as anindication that such functional/operational technical descriptions areabstract ideas, or mere expressions of abstract ideas. In fact, asoutlined herein, in the technological arts this is simply not true. Whenviewed through the tools available to those of skill in the art, suchfunctional/operational technical descriptions are seen as specifyinghardware configurations of almost unimaginable complexity.

As outlined above, the reason for the use of functional/operationaltechnical descriptions is at least twofold. First, the use offunctional/operational technical descriptions allows near-infinitelycomplex machines and machine operations arising from interchainedhardware elements to be described in a manner that the human mind canprocess (e.g., by mimicking natural language and logical narrativeflow). Second, the use of functional/operational technical descriptionsassists the person of skill in the art in understanding the describedsubject matter by providing a description that is more or lessindependent of any specific vendor's piece(s) of hardware.

The use of functional/operational technical descriptions assists theperson of skill in the art in understanding the described subject mattersince, as is evident from the above discussion, one could easily,although not quickly, transcribe the technical descriptions set forth inthis document as trillions of ones and zeroes, billions of single linesof assembly-level machine code, millions of logic gates, thousands ofgate arrays, or any number of intermediate levels of abstractions.However, if any such low-level technical descriptions were to replacethe present technical description, a person of skill in the art couldencounter undue difficulty in implementing the disclosure, because sucha low-level technical description would likely add complexity without acorresponding benefit (e.g., by describing the subject matter utilizingthe conventions of one or more vendor-specific pieces of hardware).Thus, the use of functional/operational technical descriptions assiststhose of skill in the art by separating the technical descriptions fromthe conventions of any vendor-specific piece of hardware.

In view of the foregoing, the logical operations/functions set forth inthe present technical description are representative of static orsequenced specifications of various ordered-matter elements, in orderthat such specifications may be comprehensible to the human mind andadaptable to create many various hardware configurations. The logicaloperations/functions disclosed herein should be treated as such, andshould not be disparagingly characterized as abstract ideas merelybecause the specifications they represent are presented in a manner thatone of skill in the art can readily understand and apply in a mannerindependent of a specific vendor's hardware implementation.

Those having skill in the art will recognize that the state of the arthas progressed to the point where there is little distinction leftbetween hardware, software, and/or firmware implementations of aspectsof systems; the use of hardware, software, and/or firmware is generally(but not always, in that in certain contexts the choice between hardwareand software can become significant) a design choice representing costvs. efficiency tradeoffs. Those having skill in the art will appreciatethat there are various vehicles by which processes and/or systems and/orother technologies described herein can be effected (e.g., hardware,software, and/or firmware), and that the preferred vehicle will varywith the context in which the processes and/or systems and/or othertechnologies are deployed. For example, if an implementer determinesthat speed and accuracy are paramount, the implementer may opt for amainly hardware and/or firmware vehicle; alternatively, if flexibilityis paramount, the implementer may opt for a mainly softwareimplementation; or, yet again alternatively, the implementer may opt forsome combination of hardware, software, and/or firmware in one or moremachines, compositions of matter, and articles of manufacture, limitedto patentable subject matter under 35 USC 101. Hence, there are severalpossible vehicles by which the processes and/or devices and/or othertechnologies described herein may be effected, none of which isinherently superior to the other in that any vehicle to be utilized is achoice dependent upon the context in which the vehicle will be deployedand the specific concerns (e.g., speed, flexibility, or predictability)of the implementer, any of which may vary. Those skilled in the art willrecognize that optical aspects of implementations will typically employoptically-oriented hardware, software, and or firmware.

In some implementations described herein, logic and similarimplementations may include software or other control structures.Electronic circuitry, for example, may have one or more paths ofelectrical current constructed and arranged to implement variousfunctions as described herein. In some implementations, one or moremedia may be configured to bear a device-detectable implementation whensuch media holds or transmits device detectable instructions operable toperform as described herein. In some variants, for example,implementations may include an update or modification of existingsoftware or firmware, or of gate arrays or programmable hardware, suchas by performing a reception of or a transmission of one or moreinstructions in relation to one or more operations described herein.Alternatively or additionally, in some variants, an implementation mayinclude special-purpose hardware, software, firmware components, and/orgeneral-purpose components executing or otherwise invokingspecial-purpose components. Specifications or other implementations maybe transmitted by one or more instances of tangible transmission mediaas described herein, optionally by packet transmission or otherwise bypassing through distributed media at various times.

Alternatively or additionally, implementations may include executing aspecial-purpose instruction sequence or invoking circuitry for enabling,triggering, coordinating, requesting, or otherwise causing one or moreoccurrences of virtually any functional operations described herein. Insome variants, operational or other logical descriptions herein may beexpressed as source code and compiled or otherwise invoked as anexecutable instruction sequence. In some contexts, for example,implementations may be provided, in whole or in part, by source code,such as C++, or other code sequences. In other implementations, sourceor other code implementation, using commercially available and/ortechniques in the art, may be compiled//implemented/translated/convertedinto a high-level descriptor language (e.g., initially implementingdescribed technologies in C or C++ programming language and thereafterconverting the programming language implementation into alogic-synthesizable language implementation, a hardware descriptionlanguage implementation, a hardware design simulation implementation,and/or other such similar mode(s) of expression). For example, some orall of a logical expression (e.g., computer programming languageimplementation) may be manifested as a Verilog-type hardware description(e.g., via Hardware Description Language (HDL) and/or Very High SpeedIntegrated Circuit Hardware Descriptor Language (VHDL)) or othercircuitry model which may then be used to create a physicalimplementation having hardware (e.g., an Application Specific IntegratedCircuit). Those skilled in the art will recognize how to obtain,configure, and optimize suitable transmission or computational elements,material supplies, actuators, or other structures in light of theseteachings.

Those skilled in the art will recognize that it is common within the artto implement devices and/or processes and/or systems, and thereafter useengineering and/or other practices to integrate such implemented devicesand/or processes and/or systems into more comprehensive devices and/orprocesses and/or systems. That is, at least a portion of the devicesand/or processes and/or systems described herein can be integrated intoother devices and/or processes and/or systems via a reasonable amount ofexperimentation. Those having skill in the art will recognize thatexamples of such other devices and/or processes and/or systems mightinclude—as appropriate to context and application—all or part of devicesand/or processes and/or systems of (a) an air conveyance (e.g., anairplane, rocket, helicopter, etc.), (b) a ground conveyance (e.g., acar, truck, locomotive, tank, armored personnel carrier, etc.), (c) abuilding (e.g., a home, warehouse, office, etc.), (d) an appliance(e.g., a refrigerator, a washing machine, a dryer, etc.), (e) acommunications system (e.g., a networked system, a telephone system, aVoice over IP system, etc.), (f) a business entity (e.g., an InternetService Provider (ISP) entity such as Comcast Cable, Qwest, SouthwesternBell, etc.), or (g) a wired/wireless services entity (e.g., Sprint,Cingular, Nextel, etc.), etc.

In certain cases, use of a system or method may occur in a territoryeven if components are located outside the territory. For example, in adistributed computing context, use of a distributed computing system mayoccur in a territory even though parts of the system may be locatedoutside of the territory (e.g., relay, server, processor, signal-bearingmedium, transmitting computer, receiving computer, etc. located outsidethe territory).

A sale of a system or method may likewise occur in a territory even ifcomponents of the system or method are located and/or used outside theterritory. Further, implementation of at least part of a system forperforming a method in one territory does not preclude use of the systemin another territory

In a general sense, those skilled in the art will recognize that thevarious embodiments described herein can be implemented, individuallyand/or collectively, by various types of electro-mechanical systemshaving a wide range of electrical components such as hardware, software,firmware, and/or virtually any combination thereof, limited topatentable subject matter under 35 U.S.C. 101; and a wide range ofcomponents that may impart mechanical force or motion such as rigidbodies, spring or torsional bodies, hydraulics, electro-magneticallyactuated devices, and/or virtually any combination thereof.Consequently, as used herein, “electro-mechanical system” includes, butis not limited to, electrical circuitry operably coupled with atransducer (e.g., an actuator, a motor, a piezoelectric crystal, a MicroElectro Mechanical System (MEMS), etc.), electrical circuitry having atleast one discrete electrical circuit, electrical circuitry having atleast one integrated circuit, electrical circuitry having at least oneapplication specific integrated circuit, electrical circuitry forming ageneral purpose computing device configured by a computer program (e.g.,a general purpose computer configured by a computer program which atleast partially carries out processes and/or devices described herein,or a microprocessor configured by a computer program which at leastpartially carries out processes and/or devices described herein),electrical circuitry forming a memory device (e.g., forms of memory(e.g., random access, flash, read only, etc.)), electrical circuitryforming a communications device (e.g., a modem, communications switch,optical-electrical equipment, etc.), and/or any non-electrical analogthereto, such as optical or other analogs (e.g., graphene basedcircuitry). Those skilled in the art will also appreciate that examplesof electro-mechanical systems include, but are not limited to, a varietyof consumer electronics systems, medical devices, as well as othersystems such as motorized transport systems, factory automation systems,security systems, and/or communication/computing systems. Those skilledin the art will recognize that electro-mechanical as used herein is notnecessarily limited to a system that has both electrical and mechanicalactuation except as context may dictate otherwise.

In a general sense, those skilled in the art will recognize that thevarious aspects described herein which can be implemented, individuallyand/or collectively, by a wide range of hardware, software, firmware,and/or any combination thereof can be viewed as being composed ofvarious types of “electrical circuitry.” Consequently, as used herein“electrical circuitry” includes, but is not limited to, electricalcircuitry having at least one discrete electrical circuit, electricalcircuitry having at least one integrated circuit, electrical circuitryhaving at least one application specific integrated circuit, electricalcircuitry forming a general purpose computing device configured by acomputer program (e.g., a general purpose computer configured by acomputer program which at least partially carries out processes and/ordevices described herein, or a microprocessor configured by a computerprogram which at least partially carries out processes and/or devicesdescribed herein), electrical circuitry forming a memory device (e.g.,forms of memory (e.g., random access, flash, read only, etc.)), and/orelectrical circuitry forming a communications device (e.g., a modem,communications switch, optical-electrical equipment, etc.). Those havingskill in the art will recognize that the subject matter described hereinmay be implemented in an analog or digital fashion or some combinationthereof.

Those skilled in the art will recognize that at least a portion of thedevices and/or processes described herein can be integrated into animage processing system. Those having skill in the art will recognizethat a typical image processing system generally includes one or more ofa system unit housing, a video display device, memory such as volatileor non-volatile memory, processors such as microprocessors or digitalsignal processors, computational entities such as operating systems,drivers, application programs, one or more interaction devices (e.g., atouch pad, a touch screen, an antenna, etc.), and/or control systemsincluding feedback loops and control motors (e.g., feedback for sensinglens position and/or velocity; control motors for moving/distortinglenses to give desired focuses). An image processing system may beimplemented utilizing suitable commercially available components, suchas those typically found in digital still systems and/or digital motionsystems.

Those skilled in the art will recognize that at least a portion of thedevices and/or processes described herein can be integrated into a dataprocessing system. Those having skill in the art will recognize that adata processing system generally includes one or more of a system unithousing, a video display device, memory such as volatile or non-volatilememory, processors such as microprocessors or digital signal processors,computational entities such as operating systems, drivers, graphicaluser interfaces, and application programs, one or more interactiondevices (e.g., a touch pad, a touch screen, an antenna, etc.), and/orcontrol systems including feedback loops and control motors (e.g.,feedback for sensing position and/or velocity; control motors for movingand/or adjusting components and/or quantities). A data processing systemmay be implemented utilizing suitable commercially available components,such as those typically found in data computing/communication and/ornetwork computing/communication systems.

Those skilled in the art will recognize that at least a portion of thedevices and/or processes described herein can be integrated into a motesystem. Those having skill in the art will recognize that a typical motesystem generally includes one or more memories such as volatile ornon-volatile memories, processors such as microprocessors or digitalsignal processors, computational entities such as operating systems,user interfaces, drivers, sensors, actuators, application programs, oneor more interaction devices (e.g., an antenna USB ports, acoustic ports,etc.), control systems including feedback loops and control motors(e.g., feedback for sensing or estimating position and/or velocity;control motors for moving and/or adjusting components and/orquantities). A mote system may be implemented utilizing suitablecomponents, such as those found in mote computing/communication systems.Specific examples of such components entail such as Intel Corporation'sand/or Crossbow Corporation's mote components and supporting hardware,software, and/or firmware.

For the purposes of this application, “cloud” computing may beunderstood as described in the cloud computing literature. For example,cloud computing may be methods and/or systems for the delivery ofcomputational capacity and/or storage capacity as a service. The “cloud”may refer to one or more hardware and/or software components thatdeliver or assist in the delivery of computational and/or storagecapacity, including, but not limited to, one or more of a client, anapplication, a platform, an infrastructure, and/or a server. The cloudmay refer to any of the hardware and/or software associated with aclient, an application, a platform, an infrastructure, and/or a server.For example, cloud and cloud computing may refer to one or more of acomputer, a processor, a storage medium, a router, a switch, a modem, avirtual machine (e.g., a virtual server), a data center, an operatingsystem, a middleware, a firmware, a hardware back-end, a softwareback-end, and/or a software application. A cloud may refer to a privatecloud, a public cloud, a hybrid cloud, and/or a community cloud. A cloudmay be a shared pool of configurable computing resources, which may bepublic, private, semi-private, distributable, scaleable, flexible,temporary, virtual, and/or physical. A cloud or cloud service may bedelivered over one or more types of network, e.g., a mobilecommunication network, and the Internet.

As used in this application, a cloud or a cloud service may include oneor more of infrastructure-as-a-service (“IaaS”), platform-as-a-service(“PaaS”), software-as-a-service (“SaaS”), and/or desktop-as-a-service(“DaaS”). As a non-exclusive example, IaaS may include, e.g., one ormore virtual server instantiations that may start, stop, access, and/orconfigure virtual servers and/or storage centers (e.g., providing one ormore processors, storage space, and/or network resources on-demand,e.g., EMC and Rackspace). PaaS may include, e.g., one or more softwareand/or development tools hosted on an infrastructure (e.g., a computingplatform and/or a solution stack from which the client can createsoftware interfaces and applications, e.g., Microsoft Azure). SaaS mayinclude, e.g., software hosted by a service provider and accessible overa network (e.g., the software for the application and/or the dataassociated with that software application may be kept on the network,e.g., Google Apps, SalesForce). DaaS may include, e.g., providingdesktop, applications, data, and/or services for the user over a network(e.g., providing a multi-application framework, the applications in theframework, the data associated with the applications, and/or servicesrelated to the applications and/or the data over the network, e.g.,Citrix). The foregoing is intended to be exemplary of the types ofsystems and/or methods referred to in this application as “cloud” or“cloud computing” and should not be considered complete or exhaustive.

One skilled in the art will recognize that the herein describedcomponents (e.g., operations), devices, objects, and the discussionaccompanying them are used as examples for the sake of conceptualclarity and that various configuration modifications are contemplated.Consequently, as used herein, the specific exemplars set forth and theaccompanying discussion are intended to be representative of their moregeneral classes. In general, use of any specific exemplar is intended tobe representative of its class, and the non-inclusion of specificcomponents (e.g., operations), devices, and objects should not be takenas limiting.

The herein described subject matter sometimes illustrates differentcomponents contained within, or connected with, different othercomponents. It is to be understood that such depicted architectures aremerely exemplary, and that in fact many other architectures may beimplemented which achieve the same functionality. In a conceptual sense,any arrangement of components to achieve the same functionality iseffectively “associated” such that the desired functionality isachieved. Hence, any two components herein combined to achieve aparticular functionality can be seen as “associated with” each othersuch that the desired functionality is achieved, irrespective ofarchitectures or intermedial components. Likewise, any two components soassociated can also be viewed as being “operably connected” or “operablycoupled” to each other to achieve the desired functionality, and any twocomponents capable of being so associated can also be viewed as being“operably couplable” to each other to achieve the desired functionality.Specific examples of operably couplable include, but are not limited, tophysically mateable and/or physically interacting components, and/orwirelessly interactable, and/or wirelessly interacting components,and/or logically interacting, and/or logically interactable components.

To the extent that formal outline headings are present in thisapplication, it is to be understood that the outline headings are forpresentation purposes, and that different types of subject matter may bediscussed throughout the application (e.g., device(s)/structure(s) maybe described under process(es)/operations heading(s) and/orprocess(es)/operations may be discussed under structure(s)/process(es)headings and/or descriptions of single topics may span two or more topicheadings). Hence, any use of formal outline headings in this applicationis for presentation purposes, and is not intended to be in any waylimiting.

Throughout this application, examples and lists are given, withparentheses, the abbreviation “e.g.,” or both. Unless explicitlyotherwise stated, these examples and lists are merely exemplary and arenon-exhaustive. In most cases, it would be prohibitive to list everyexample and every combination. Thus, smaller, illustrative lists andexamples are used, with focus on imparting understanding of the claimterms rather than limiting the scope of such terms.

With respect to the use of substantially any plural and/or singularterms herein, those having skill in the art can translate from theplural to the singular and/or from the singular to the plural as isappropriate to the context and/or application. The varioussingular/plural permutations are not expressly set forth herein for sakeof clarity.

One skilled in the art will recognize that the herein describedcomponents (e.g., operations), devices, objects, and the discussionaccompanying them are used as examples for the sake of conceptualclarity and that various configuration modifications are contemplated.Consequently, as used herein, the specific exemplars set forth and theaccompanying discussion are intended to be representative of their moregeneral classes. In general, use of any specific exemplar is intended tobe representative of its class, and the non-inclusion of specificcomponents (e.g., operations), devices, and objects should not be takenas limiting.

Although one or more users may be shown and/or described herein as asingle illustrated figure, those skilled in the art will appreciate thatone or more users may be representative of one or more human users,robotic users (e.g., computational entity), and/or substantially anycombination thereof (e.g., a user may be assisted by one or more roboticagents) unless context dictates otherwise. Those skilled in the art willappreciate that, in general, the same may be said of “sender” and/orother entity-oriented terms as such terms are used herein unless contextdictates otherwise.

In some instances, one or more components may be referred to herein as“configured to,” “configured by,” “configurable to,” “operable/operativeto,” “adapted/adaptable,” “able to,” “conformable/conformed to,” etc.Those skilled in the art will recognize that such terms (e.g.“configured to”) generally encompass active-state components and/orinactive-state components and/or standby-state components, unlesscontext requires otherwise.

In the following detailed description, reference is made to theaccompanying drawings, which form a part hereof. In the drawings,similar symbols typically identify similar or identical components oritems, unless context dictates otherwise. The illustrative embodimentsdescribed in the detailed description, drawings, and claims are notmeant to be limiting. Other embodiments may be utilized, and otherchanges may be made, without departing from the spirit or scope of thesubject matter presented here.

One of the newest trends in the field of transportation servicesparticularly in urban settings is the development of transportationnetworking services provided by web-based companies such as Uber andLyft that allow users to retain drivers/vehicles for transportationservices through, for example, mobile applications. The increasinglypopularity of such “ridesharing” services have already made some of theearly entrants in this new field household names. As with many newtechnological ventures, the functionalities provided through suchservices are somewhat limited. However there appears to be ampleopportunities for adding new and value adding functionalities to suchservices (as well as to more traditional transportation services such asTaxi services) in order to provide more robust transportation networkingsystems.

Generally, these types of online transportation services provideservices and functionalities that are already provided by traditionaltaxi and limo companies but being provided through the latesttechnological innovations (e.g., using the Internet and mobile devices,such as Smartphones, in order to request transport services). Onepossible future avenue for growth is providing true ridesharing services(e.g., carpooling) where a group of nonaffiliated passengers (e.g.,passengers or end users who do not have any social, business, and/orprofessional relationship with each other) are assigned to betransported by a single vehicle (note that “passengers” and “end users”will be used interchangeably herein, thus, they are synonymous unlessindicated otherwise). There are already a few online carpooling servicesthat provide some level of true carpooling services. However, thesecarpooling services generally provide basic carpooling services (e.g.,providing a listing of vehicles/drivers that are scheduled to depart ata particular future time from one departure point and going to aparticular destination point) that typically require arrangements inadvance of a carpooling trip (e.g., taking a group of unaffiliated endusers from one or more rendezvous locations to one or more destinationlocations).

Accordingly, network systems are proposed that coordinate matching offor-hire passenger vehicles (herein “transportation vehicle units”) toprospective carpooling passengers (e.g., end users) in real-time (e.g.,to assign a prospective passenger to a carpooling vehicle that isalready en route to or is already transporting other passengers). Insome cases, these network systems may be able to coordinate the matchingof a transportation vehicle unit with one or more end users (e.g.,passengers or customers) even when, for example, the transportationvehicle unit is already en route to or is already transporting one ormore other end users. The matching of a transportation vehicle unit thatmay already be transporting passengers (e.g., “old” passengers) with“new” passengers may be based on a number of factors including spaceavailability of the transportation vehicle unit to accommodate the newpassengers, the current location of the transportation vehicle unitrelative to the pick-up or rendezvous location for the new passengers(which may be the current location of the new passengers), the proximityof the destination of the new passengers to the destination of the oldpassengers, and so forth.

One drawback that these network systems (e.g., network servers) may haveis that in some situations they may not always have the most up-to-dateinformation related to current passenger transport obligations oftransportation vehicle units. Thus, in order to ensure, for example,that a particular transportation vehicle unit will be able to transportone or more “new” end users without violating current passengertransport obligations of the transportation vehicle unit, systems andmethods are provided herein that may be implemented locally at thetransportation vehicle unit and that may be designed to, among otherthings, verify or confirm that one or more directives that direct thetransportation vehicle unit, which is already en route to or is alreadytransporting a first end user, to transport a second end user whiletransporting the first end user does not violate one or more obligationsto transport the first end user (e.g., an obligation to transport thefirst end user to a destination location without significant delays).

In various embodiments, the verification or confirmation process may beperformed by comparing the requirements for transporting the second enduser to the requirements for transporting the first end user. In someembodiments, the systems and methods may be implemented by a transportcomputing device that may be associated with a transportation vehicleunit (which includes at least a transport vehicle such as a gas orelectric powered vehicle and a human or robotic driver) that is alreadyen route to secure the first end user or that is already transportingthe first end user. In some cases, the transport computing device may bea mobile computing device such as a Smartphone or a tablet computer thatexecutes specialized software, or maybe a dedicated computing devicewith, for example, specialized hardware, software, and/or firmware andspecifically tailored to perform the various functions and operations tobe described herein.

Referring now to FIG. 1, which illustrates a transport computing device10* operating in an exemplary environment 100. In various embodiments,the various operations and functionalities to be described herein may beimplemented by the transport computing device 10*, which in some cases,may be associated with a transportation vehicle unit 20. The transportcomputing device 10* may be designed to, among other things, receive oneor more first directives that direct a transportation vehicle unit 20 totransport a first end user 12 a; receive while the transportationvehicle unit 20 is en route to or is transporting the first end user 12a, one or more second directives that direct (e.g., instruct) thetransportation vehicle unit 20 to transport a second end user 12 b whiletransporting the first end user 12 a, the transportation vehicle unit 20having been determined (e.g., determined remotely by, for example, areal-time carpooling management system 16) to be able to accommodatetransport of the second end user 12 b while transporting the first enduser 12 a; and verify or confirm that compliance with the one or moresecond directives will not conflict with one or more obligations totransport the first end user 12 a by the transportation vehicle unit 20.

Note that for purposes of the following description “*” represents awildcard. Thus, references in the following description to, for example,“transport computing device 10*” may be in reference to the transportcomputing device 10′ of FIG. 2A, as well as to the transport computingdevice 10″ of FIG. 2B, which are two different implementations of thetransport computing device 10* of FIG. 1.

Referring back to FIG. 1, in various embodiments, the transportcomputing vehicle unit 20 may be in communication with a variety ofentities via one or more wireless and/or wired networks 18 including,for example, one or more end users 12* (via one or more end user devices14 such as Smartphones), a real-time carpooling coordinating system 15,and/or a real-time carpooling management system 16. In this exampleillustration, the end users 12* (a first end user 12 a and a second enduser 12 b) are unaffiliated parties needing transportation services.Note that for ease of illustration and explanation, only two end users,a first end user 12 a and a second end user 12 b, are illustrated inFIG. 1. However, those of ordinary skill in the art will recognize thatin alternative embodiments many more end users 12* (as well as many moretransportation vehicle units 20) may be included in the networkenvironment of FIG. 1.

The real-time carpooling management system 16 may be one or more networkservers that coordinates and matches one or more end users 12* to atransportation vehicle unit 20 for transport to their destinations. Thematching operations performed by the real-time carpooling managementsystem 16 may be as a result of making a determination as whether, forexample, a particular transportation vehicle unit 20 is able toaccommodate transport of one or more end users (e.g., the second enduser 12 b) when the particular transportation vehicle unit 20 is alreadyen route to or is already transporting one or more other end users(e.g., the first end user 12 a). A number of factors may be consideredin determining whether the particular transportation vehicle unit 20 isable to accommodate transport of the one or more end users (the secondend user 12 b) while transporting one or more other end users (e.g., thefirst end user 12 a) including, for example, whether there is sufficientavailable passenger space for the end users (e.g., the second end user12 b), whether the transportation vehicle unit 20 is in the proximatevicinity of the pickup location (e.g., rendezvous location which, insome cases, may be the current location) for the one or more end users(e.g., the second end user 12 b), whether the transportation vehicleunit 20 will be traveling near to the destination location of the one ormore end users (e.g., the second end user 12 b), whether adding the oneor more end users (e.g., the second end user 12 b) will causesignificant delay to the transport of the one or more other end users(e.g., the first end user 12 a) in reaching the one or more other endusers' destination(s), and so forth.

The one or more wireless and/or wired networks 18 may comprise of, forexample, one or more of a local area network (LAN), metropolitan areanetwork (MAN), a wireless local area network (WLAN), a personal areanetwork (PAN), a Worldwide Interoperability for Microwave Access(WiMAX), public switched telephone network (PTSN), a general packetradio service (GPRS) network, a cellular network, a Client/Servernetwork, a virtual private network (VPN), and so forth. Note again thatfor ease of illustration and explanation, FIG. 1 does not illustratemultiple transportation vehicle units 20 being in communication with thereal-time carpooling management system 16 nor more than two end users12* being in communication with the real-time carpooling managementsystem 16. However, for purposes of the following description, thereal-time carpooling management system 16 may, in fact, be incommunication with multiple transportation vehicle units 20 (viamultiple transport computing devices 10*) and numerous end users 12*.

In some cases, the real-time carpooling management system 16, which mayor may not be located overseas or across national borders, maycommunicate with a transportation vehicle unit 20 (via transportcomputing device 10*) through a real-time carpooling coordinating system15, which may be a locally based network server(s). In order to try tomatch a prospective passenger, such as the second end user 12 b of FIG.1, to a transportation vehicle unit 20 for transport, the real-timecarpooling management system 16 may check the current end user transportobligations (e.g., obligations for transporting other passengers such asthe first end user 12 a of FIG. 1) of the transportation vehicle unit20. That is, a transportation vehicle unit 20 (via their own associatedtransport computing device 10*) may periodically or continuously provideits current outstanding obligations (including no obligation) fortransporting end users to the real-time carpooling management system 16(sometimes via the real-time carpooling coordinating system 15). Bycomparing the current end user transport obligations (e.g., anobligation to transport the first end user 12 a of FIG. 1) of thetransportation vehicle unit 20 with the requirements for transporting aprospective passenger (e.g., the second end user 12 b) and determiningthat transport of the second end user 12 b will not conflict with theobligation to transport the first end user 12 a, the real-timecarpooling management system 16 may match the prospective passenger(e.g., the second end user 12 b) to the appropriate transportationvehicle unit 20. Note the phrase “real-time” is used herein becausewhen, for example, a second end user 12 b is being assigned to atransportation vehicle unit 20 for transport, the transportation vehicleunit 20 may already be en route to or is already transporting a firstend user 12 a.

Note, however, that in many situations the matching operations (that maybe performed by the real-time carpooling management system 16) may befaulty because the real-time carpooling management system 16 may nothave the most current information related to the current end usertransport obligations of a transportation vehicle unit 20. This may beas a result of many factors including, for example, the reporting ofcurrent end user transport obligations by the transportation vehicleunit 20 may only be random or sporadic due to communication disruptionsbetween the transportation vehicle unit 20 and the real-time carpoolingmanagement system 16, or failure of human drivers to record/reportchanges to end user transport obligations.

In order to facilitate understanding of the various concepts related tothe processes and operations to be described herein, the followingillustrative scenario is provided that shows how a transportationvehicle unit 20 may become obligated to transport a first end user 12 aand how a second end user 12 b (e.g., a prospective passenger) may beassigned to be transported by the same transportation vehicle unit 20while transporting the first end user 12 a, the assignment of the secondend user 12 b to the transportation vehicle unit 20 being executed whilethe transportation vehicle unit 20 is already en route to (e.g.,traveling to a rendezvous location to secure the first end user 12 a) oris already transporting the first end user 12 a (note that this mayinclude the span in time when the transportation vehicle unit 20 is atthe rendezvous location awaiting for the arrival of the first end user12 a). When an end user, such as the first end user 12 a of FIG. 1,seeks transportation services, a transport request may be transmitted bythe first end user 12 a using an end user device 14. The transportrequest may then be received by the real-time carpooling managementsystem 16 (in some cases, via the real-time carpooling coordinatingsystem 15). In various embodiments, the transport request that may betransmitted may be a request that specifically requests for a carpoolingvehicle that may be used in order to transport other end users whiletransporting the first end user 12 a. In some cases, the transportationvehicle unit 20 that may be assigned to transport the first end user 12a may only be permitted (e.g., as permitted by the first end user 12 aor by a third party such as a ridesharing company) to transport otherend users while transporting the first end user 12 a only when certainconditions can be met (e.g., no significant delay, such as no more than15 minute delay, for transporting the first end user 12 a to his or herdestination and as a result of the transportation vehicle unit 20transporting other end users while transporting the first end user 12a).

The real-time carpooling management system 16 upon receiving the requestfrom the first end user 12 a may then assign a transportation vehicleunit 20 to transport the first end user 12 a based on one or morefactors including the current availability the transportation vehicleunit 20 (e.g., whether the transportation vehicle unit 20 is in-serviceor off-duty or whether it is in the proximate vicinity of the first enduser 12 a), and the current outstanding passenger transport obligationsof the transportation vehicle unit 20. That is, based on the knownobligations and status of the transportation vehicle units 20, thereal-time carpooling management system 16 may determine that thetransportation vehicle unit 20 should be assigned to transport the firstend user 12 a.

In any event, after determining/selecting the transportation vehicleunits 20 for transporting the first end user 20, the real-timecarpooling management system 16 may direct or instruct the selectedtransportation vehicle unit 20 to transport the first end user 12 a bytransmitting to a transport computing device 10* associated with theselected transportation vehicle unit 20 one or more first directivesthat direct (e.g., instruct) the selected transportation vehicle unit 20to rendezvous with the first end user 12 a at a first end userrendezvous location (which, in some cases, may be the location of thefirst end user 12 a at the time when the first end user 12 a requestedtransportation services). In some cases, the real-time carpoolingmanagement system 16 may transmit the one or more first directives to atransport computing device 10* associated with the transportationvehicle unit 20 indirectly through the real-time carpooling coordinatingsystem 15.

The one or more first directives that may be transmitted to thetransport computing device 10* may indicate a variety of informationincluding a first end user rendezvous location for rendezvousing withthe first end user 12 a, a first end user destination location,carpooling preferences (alternatively, the carpooling preferences may bereceived separately from the one or more first directives), and soforth. Carpooling preferences may include, for example, the amount oftravel delay that may be acceptable for a particular end user and as aresult of transporting other end users, maximum number of drop-offs(e.g., passenger offload stops) permitted prior to a particular end userbeing dropped-off, and so forth. Upon the one or more first directivesbeing received and accepted by the logic of the transport computingdevice 10*, the one or more directives may become one or moreobligations for transporting the first end user 12 a. After the one ormore first directives are accepted, the real-time carpooling managementsystem 16 may transmit (in some cases via the real-time carpoolingcoordinating system 15) a confirmation that the one or more firstdirectives have been accepted.

While the transportation vehicle unit 20 is still en route to a firstend user rendezvous location for rendezvousing with the first end user12 a or while the transportation vehicle unit 20 is transporting thefirst end user 12 a, a second end user 12 b may transmit a request fortransportation services (which may or may not request specifically forcarpooling services—e.g., share a ride with other end users) to thereal-time carpooling management system 16. After determining that thetransportation vehicle unit 20 is able to accommodate transport of thesecond end user 12 b while transporting the first end user 12 a, thereal-time carpooling management system 16 may then transmit to thetransport computing device 10* associated with the transportationvehicle unit 20 one or more second directives that direct thetransportation vehicle unit 20 to pick-up and transport the second enduser 12 b while transporting the first end user 12 a. The determinationas to whether the transportation vehicle unit 20 may accommodatetransport of the second end user 12 b while transporting the first enduser 12 a may be based on one or more factors including, for example, adetermination that the transportation vehicle unit 20 having sufficientspace to accommodate the second end user 12 b, a determination that thetransportation vehicle unit 20 is in the proximate vicinity of thesecond end user 12 b, a determination the transportation vehicle unit 20will be traveling near to the destination location of the second enduser 12 b while transporting the first end user 12 a or other end users,a determination that transport of the first end user 12 a and the secondend user 12 b together will comply with the carpooling preferences ofthe first end user 12 a, the second end user 12 b, or a third party, andso forth.

The one or more second directives that are received by the transportcomputing device 10* may include a variety of information including enduser information (e.g., identity and/or image of the second end user 12b), a rendezvous location for rendezvousing with the second end user 12b, a destination location for the second end user 12 b, end usercarpooling preferences of the second end user 12 b, and so forth. Afterreceiving the one or more second directives, the transport computingdevice 10* associated with the transportation vehicle unit 20 may verifyor confirm that the one or more second directives do not conflict withone or more obligations to transport the first end user 12 a. Theverification or confirmation may be needed because the real-timecarpooling management system 16 will often not have the most up-to-datestatus and obligation information related to the transportation vehicleunit 20. Instead, only the transport computing device 10* may have themost up-to-date status and passenger obligation information of thetransportation vehicle unit 20.

The verification (e.g., confirmation) process may involve looking at anumber of factors in order to confirm that the one or more seconddirectives do not conflict with the one or more obligations to transportthe first end user 12 a. These factors may be the same factorsconsidered by the real-time carpooling management system 16 indetermining that the transportation vehicle unit 20 is able toaccommodate transport of the second end user 12 b. These factorsinclude, for example, a determination that the transportation vehicleunit 20 having sufficient space to accommodate the second end user 12 b,a determination that the transportation vehicle unit 20 is in theproximate vicinity of the second end user 12 b, a determination thetransportation vehicle unit 20 will be traveling near to the destinationlocation of the second end user 12 b while transporting the first enduser 12 a or other end users, a determination that transport of thefirst end user 12 a and the second end user 12 b together will complywith the carpooling preferences of the first end user 12 a, the secondend user 12 b, or a third party, and so forth. In some cases, theverification or confirmation process may also include a determination oftransport rate or rates (e.g., transport fees) for the first end user 12a and/or the second end user 12 b that may be based on thetransportation vehicle unit 20 transporting both the first end user 12 aand the second end user 12 b. A more detailed discussion related to theconfirmation/verification procedures will be provided in the processesto be described herein.

Once the logic of the transport computing device 10* of thetransportation vehicle unit 20 verifies or confirms that the one or moresecond directives do not conflict with the one or more obligations ofthe transportation vehicle unit 20 to transport the first end user 12 a,the transport computing device 10* may transmit to, for example, thereal-time carpooling management system 16 and/or to one or more end userdevices 14 one or more confirmations that indicate that thetransportation vehicle unit 20 will, in fact, be transporting the secondend user 12 b. If, on the other hand, the logic of the transportcomputing device 10* is unable to make the verification or confirmation,then the transport computing device 10* may transmit to the real-timecarpooling management system 16 a notification that the transportationvehicle unit 20 is unable to accommodate transport of the second enduser 12 b.

After the logic of the transport computing device 10* of thetransportation vehicle unit 20 verifies or confirms that the one or moresecond directives do not conflict with the one or more obligations ofthe transportation vehicle unit 20 to transport the first end user 12 a,the transport computing device 10* may also present one or moreinstructive directives that direct (e.g., instructs) the transportationvehicle unit 20 to rendezvous with and transport the second end user 12b. In cases where the transportation vehicle unit 20 employs a humandriver, the one or more instructive directives may be visually and/oraudibly presented. In other cases where the transportation vehicle unit20 employs a robotic driver system 450 (see FIG. 4E) the one or moreinstructive directives may be electronically presented to a navigationsystem 452 of the robotic driver system 450.

Turning now to FIGS. 4A to 4D, which illustrate various routes that thetransportation vehicle unit 20 of FIG. 1 may use in order to transportthe first end user 12 a and the second end user 12 b to theirdestination(s) (e.g., destination location(s)) for different examplescenarios (e.g., scenario 1, scenario 2, scenario 3, and scenario 4).These scenarios may better facilitate understanding of the variousconcepts to be introduced with respect to the various operations andprocesses to be described herein. Referring particularly now to FIG. 4A,which illustrates a route that the transportation vehicle unit 20 ofFIG. 1 may take in order to transport the first end user 12 a and thesecond end user 12 b to their destination locations (e.g., 1.sup.st enduser destination location 404 and 2.sup.nd end user destination location410) in accordance with scenario 1. In scenario 1, the transportationvehicle unit 20 is en route to rendezvous with the first end user 12 aat a first end user rendezvous location 402 when it is assigned/selectedto transport the second end user 12 b.

As illustrated, the transportation vehicle unit (TVU) 20 is depicted asbeing currently en route to rendezvous with the first end user 12 a atthe first end user rendezvous location 402 and being currently locatedat current location 406 when it is selected for transport of the secondend user 12 b. FIG. 4A further illustrates an original direct route 403that the TVU (e.g., transportation vehicle unit 20 of FIG. 1) could havetaken to transport the first end user 12 a from the first end userrendezvous location 402 to a first end user destination location 404 ifthe TVU was not selected for transporting the second end user 12 b.However, because the TVU is selected to transport the second end user 12b, the TVU must take detour 414 a in order to secure the second end user12 b from second end user rendezvous location 408 and take detour 414 bto drop off the second end user 12 b at a second end user destinationlocation 410. As a result, the first end user 12 a may be delayed inbeing transported to his/her destination location (e.g., first end userdestination location 404). In various embodiments, the transport of thesecond end user 12 b by the TVU may be permitted so long as the delay intransporting the first end user 12 a is permitted by the first end user12 a and/or permitted by a third party such as a ridesharing companyassociated with the real-time carpooling management system 16.

Turning now to FIG. 4B, which illustrates a scenario 2 in which the TVU(e.g., the transportation vehicle unit 20 of FIG. 1) uses a particularroute (e.g., direct route 420) to transport the first end user 12 a andthe second end user 12 b to a common destination location 422. Incontrast to scenario 1 illustrated in FIG. 4A, in scenario 2 both thefirst end user 12 a and the second end user 12 b are scheduled to go tothe same destination (e.g., common destination location 422). Further,the second end user rendezvous location 408 for rendezvousing with thesecond end user 12 b is located along the direct route 420 fortransporting the first end user 12 a from a first end user rendezvouslocation 402 to the first end user's destination location (e.g., commondestination location 422). In FIG. 4B, the TVU is currently located, ata point in time when the TVU (e.g., transportation vehicle unit 20) isselected for transport of the second end user 12 b, at current location406 that is the same as the first end user rendezvous location 402.Thus, in scenario 2, the first end user 12 a will not incur asignificant delay because the second end user rendezvous location 408 islocated along the direct route 420 and the second end user 12 b is goingto the same common destination location 422 as the first end user 12 a.

Scenario 2 reflects many true life situations. For example, scenario 2may occur when a number of end users from the same general neighborhoodare intent on attending the same sporting or concert event.

FIG. 4C illustrates a scenario 3 in which the TVU (e.g., thetransportation vehicle unit 20 of FIG. 1) is already transporting thefirst end user 12 a when the transportation vehicle unit 20 is selectedor assigned (e.g., selected by the real-time carpooling managementsystem 16) to transport the second end user 12 b. As illustrated, whenthe transportation vehicle unit 20 is selected to transport the secondend user 12 b, the TVU is located at current location 406 along thedirect route 430 from the first end user rendezvous location 402 to thefirst end user destination location 404 (which continues on to secondend user destination location 410). In order to transport the second enduser 12 b, the TVU uses a detour 414 a to secure the second end user 12b at rendezvous location 408. Note that in scenario 3, the second enduser 12 b is designated to be dropped off at second end user destinationlocation 410, which is scheduled to occur after the first end user 12 ahas already been dropped off at a first end user destination location404. Thus, the delay to transport of first end user 12 a to his or herdestination location (e.g., first end user destination location 404) asa result of the transportation vehicle unit 20 transporting the secondend user 12 b may be relatively minimal. That is, the only delay to thetransport of the first end user 12 a may be as a result of thetransportation vehicle unit 20 being rerouted to rendezvous with thesecond end user 12 b at the rendezvous location 408 using detour 414 a.

FIG. 4D illustrates a scenario 4 in which the TVU (e.g., thetransportation vehicle unit 20 of FIG. 1) is to rendezvous with thefirst end user 12 a and the second end user 12 b at a common rendezvouslocation 440 and to transport the first end user 12 a and the second enduser 12 b to a common destination location 442. Because there are nodetours, there is little or no delay in transporting the first end user12 a to his/her destination (e.g., common destination location 442)except for any extended time that the TVU may have to stay at the commonrendezvous location 440 in order to wait for the arrival of the secondend user 12 b. There are several real life situations in which such ascenario can occur. For example, at the end of a sporting event such asat a football game and a number of the spectators leaving the stadiumwith the intent to go to a popular bar/nightclub.

Referring now to FIGS. 2A and 2B, which illustrate two block diagramsrepresenting two different implementations of the transport computingdevice 10* of FIG. 1. In particular, and as will be further describedherein, FIG. 2A illustrates a transport computing device 10′ that is the“hardwired” or “hard” implementation of the transport computing device10* of FIG. 1 that can implement the operations and processes to bedescribed herein. The transport computing device 10′ includes certainlogic modules including a directive receiving module 202′, anon-conflict confirming module 204′, a confirmation transmitting module206′, and an instructive directive presenting module 208′ that areimplemented using purely hardware or circuitry components (e.g.,application specific integrated circuit (or ASIC)). In contrast, FIG. 2Billustrates a transport computing device 10″ that is the “soft”implementation of the transport computing device 10* of FIG. 1 in whichcertain logic modules including a directive receiving module 202″, anon-conflict confirming module 204″, a confirmation transmitting module206″, and an instructive directive presenting module 208″ areimplemented using programmable circuitry 230 (e.g., one or moreprocessors 230 including one or more microprocessors, controllers, CPUs,GPUs, FPGAs, and/or other types of programmable circuitry) executing oneor more programming instructions (e.g., software). Note that in someembodiments, the transport computing device 10″ illustrated in FIG. 2Bmay be a general purposes computing device (e.g., a mobile computingdevice such as a Smartphone or tablet computer) that executesspecialized computer readable instructions (e.g., software). Inalternative embodiments, the transport computing device 10″ may be adedicated device designed specifically to execute the various operationsand processes to be described herein.

The embodiments of the transport computing device 10* illustrated inFIGS. 2A and 2B (e.g., the transport computing device 10′ of FIG. 2A andthe transport computing device 10″ of FIG. 2B) are two extremeimplementations of the transport computing device 10* in which all ofthe logic modules (e.g., the directive receiving module 202′, thenon-conflict confirming module 204′, the confirmation transmittingmodule 206″, and the instructive directive presenting module 208′) areimplemented using purely hardware solutions (e.g., circuitry such asASIC) as illustrated in FIG. 2A or in which all of the logic modules(e.g., the directive receiving module 202″, the non-conflict confirmingmodule 204″, the confirmation transmitting module 206″, and theinstructive directive presenting module 208″) are implemented usingsoftware solutions (e.g., programmable instructions being executed byprogrammable circuitry 230 such as field programmable gate array (FPGA)or one or more processors) as illustrated in FIG. 2B. Since there aremany ways of combining hardware, software, and/or firmware in order toimplement the various logic modules (e.g., the directive receivingmodule 202*, the non-conflict confirming module 204*, the confirmationtransmitting module 206*, and the instructive directive presentingmodule 208″), only the two extreme implementations (e.g., the purelyhardware solution as illustrated in FIG. 2A and the software solution ofFIG. 2B) are illustrated here. It should be noted here that with respectto the “soft” implementation illustrated in FIG. 2B, hardware in theform of programmable circuitry such as one or more processors 230 (orFPGA) are still needed in order to execute the software (or firmware).Further details related to the two implementations of the transportcomputing device 10* illustrated in FIGS. 2A and 2B will be provided ingreater detail below.

In some instances, one or more components may be referred to herein as“configured to,” “configured by,” “configurable to,” “operable/operativeto,” “adapted/adaptable,” “able to,” “conformable/conformed to,”“designed to,” etc. Those skilled in the art will recognize that suchterms (e.g., “configured to”) generally encompass active-statecomponents and/or inactive-state components and/or standby-statecomponents, unless context requires otherwise.

Referring particularly now to FIG. 2A, which illustrates that thetransport computing device 10′, in addition to the directive receivingmodule 202′, the non-conflict confirming module 204,′ the confirmationtransmitting module 206′, and the instructive directive presentingmodule 208′, may further include programmable circuitry 230 (e.g., oneor more processors, controllers, and so forth), a network interface 240(network interface card or NIC), memory 220, and/or a user interface250. In various embodiments, memory 220 may comprise of volatile and/ornon-volatile memory. In some embodiments, memory 220 may comprise of oneor more of mass storage device, cache memory, read-only memory (ROM),programmable read-only memory (PROM), erasable programmable read-onlymemory (EPROM), cache memory such as random access memory (RAM), flashmemory, synchronous random access memory (SRAM), dynamic random accessmemory (DRAM), and/or other types of memory devices. In someembodiments, the memory 220 may be employed to store a variety ofprogramming instructions (e.g., software) and data including dataindicating current end user transport obligations of the transportationvehicle unit 10′, carpooling preferences of end users and/or thirdparties, and so forth.

Turning now to FIG. 2B, which illustrates a transport computing device10″ in which certain logic modules (the directive receiving module 202″,the non-conflict confirming module 204″, the confirmation transmittingmodule 206″, and the instructive directive presenting module 208″) areimplemented using programmable circuitry 230 (e.g., one or moreprocessors, one or more controllers, FPGAs, and/or other types ofprogrammable circuitry). In addition, the transport computing device 10″may further include a memory 220, a network interface 240, and/or a userinterface 250 similar to the transport computing device 10′ of FIG. 2A.

In various embodiments the directive receiving module 202* of FIG. 2A or2B (e.g., the directive receiving module 202′ of FIG. 2A or thedirective receiving module 202″ of FIG. 2B) may be configured to, amongother things, receive one or more first directives that direct thetransportation vehicle unit 20 to transport a first end user 12 a. Thedirective receiving module 202* may further be configured to receive,while the transportation vehicle unit 20 is en route to secure the firstend user 12 a or is transporting the first end user 12 a, one or moresecond directives that direct the transportation vehicle unit 20 totransport a second end user 12 b while transporting the first end user12 a, the transportation vehicle unit having been determined to be ableto accommodate transport of the second end user 12 b while transportingthe first end user 12 a. In contrast, the non-conflict confirming module204* of FIG. 2A or 2B (e.g., the non-conflict confirming module 204′ ofFIG. 2A or the non-conflict confirming module 204″ of FIG. 2B) may beconfigured to, among other things, verify or confirm that compliancewith the one or more second directives will not conflict with one ormore obligations to transport the first end user 12 a by thetransportation vehicle unit 20. Meanwhile, the confirmation transmittingmodule 206* of FIG. 2A or 2B may be configured to, among other things,transmit one or more confirmations that the one or more seconddirectives have been accepted for execution by the transportationvehicle unit 20. On the other hand, the instructive directive presentingmodule 208* of FIG. 2A or 2B may be configured to, among other things,present, in response to verification or confirmation that compliancewith the one or more second directives will not conflict with one ormore obligations to transport the first end user 12 a by thetransportation vehicle unit 20, one or more instructive directives thatdirect the transportation vehicle unit 20 to transport the second enduser 12 b.

Referring now to FIG. 3A illustrating a particular implementation of thedirective receiving module 202* (e.g., the directive receiving module202′ or the directive receiving module 202″) of FIG. 2A or 2B. Asillustrated, the directive receiving module 202* may include one or moresub-logic modules in various alternative implementations. For example,in various embodiments, the directive receiving module 202* may furtherinclude a carpooling preference receiving module 302, a transport ratedata receiving module 304, and/or an image data receiving module 306.Specific details related to the directive receiving module 202* as wellas the above-described sub-modules of the directive receiving module202* will be provided below with respect to the operations and processesto be described herein.

FIG. 3B illustrates a particular implementation of the non-conflictconfirming module 204* (e.g., the non-conflict confirming module 204′ orthe non-conflict confirming module 204″) of FIG. 2A or 2B. Asillustrated, the non-conflict confirming module 204* may include one ormore sub-logic modules in various alternative implementations. Forexample, in various embodiments, the non-conflict confirming module 204*may further include a rendezvous location proximity confirming module308, a spatial availability confirming module 310, a vicinity travelingconfirming module 312, a carpooling preference non-conflict confirmingmodule 314, and/or a transport rate ascertaining module 316. Specificdetails related to the non-conflict confirming module 204* as well asthe above-described sub-module of the non-conflict confirming module204*.

FIG. 3C illustrates a particular implementation of the instructivedirective presenting module 208* (e.g., instructive directive presentingmodule 208′ or the instructive directive presenting module 208″) of FIG.2A or 2B. As illustrated, the instructive directive presenting module208* may include one or more sub-logic modules in various alternativeimplementations. For example, in various embodiments, the instructivedirective presenting module 208* may further include a visual/audibleinstructive directive presenting module 320 and/or an electronicinstructive directive presenting module 322. Specific details related tothe instructive directive presenting module 208″ as well as theabove-described sub-module of the instructive directive presentingmodule 208* will be provided below with respect to the operations andprocesses to be described herein.

Turning now to FIG. 4E, which illustrates a block diagram of a roboticdriver system 450 that may be employed by a transportation vehicle unit20. The robotic driver system 450 may be employed in order to replace ahuman driver and may include, among other things, a transport computingdevice 10* of FIG. 2A or 2B, a navigation system 452, and atransportation vehicle control system 454. The navigation system 452 maybe designed to provide navigational functionalities (e.g., plans routesto a destination location from a starting location, keeps track of thelocation of the transportation vehicle unit 20 using GPS data, and soforth) while the transportation vehicle control system 454 may beemployed to control the various driving components (e.g., steering, gas,brakes, transmission, and so forth) of the vehicle portion (e.g., gas orelectric powered vehicle) of the transportation vehicle unit 20.

In the following, various operations associated with the above describedtransport computing device 10* (e.g., the transport computing device 10′of FIG. 2A or the transport computing device 10″ of FIG. 2B) will bepresented in accordance with various alternative embodiments. FIG. 5,for example, illustrates an operational flow 500 representing examplecomputationally-implemented operations that may be implemented for,among other things, verifying that compliance with the one or moresecond directives that direct a transportation vehicle unit 20 totransport a second end user 12 b will not conflict with one or moreobligations to transport a first end user 12 a by the transportationvehicle unit 20.

In FIG. 5 and in the following figures that include various examples ofoperational flows, discussions and explanations will be provided withrespect to the transport computing device 10* described above and asillustrated in FIGS. 2A, 2B, 3A, 3B, and 3C, and/or with respect toother examples (e.g., as provided in FIGS. 1 and 4A, 4B, 4C, 4D, and 4E)and contexts. However, it should be understood that the operationalflows may be executed in a number of other environments and contexts,and/or in modified versions of FIGS. 1, 2A, 2B, 3A, 3B, 3C, 4A, 4B, 4C,4D, and/or 4E. Also, although the various operational flows arepresented in the sequence(s) illustrated, it should be understood thatthe various operations may be performed in orders other than those whichare illustrated, or may be performed concurrently.

Further, in FIG. 5 and in the figures to follow thereafter, variousoperations may be depicted in a box-within-a-box manner. Such depictionsmay indicate that an operation in an internal box may comprise anoptional example embodiment of the operational step illustrated in oneor more external boxes. However, it should be understood that internalbox operations may be viewed as independent operations separate from anyassociated external boxes and may be performed in any sequence withrespect to all other illustrated operations, or may be performedconcurrently. Still further, these operations illustrated in FIG. 5 aswell as the other operations to be described herein are performed by atleast one of a machine, an article of manufacture, or a composition ofmatter unless indicated otherwise.

For ease of understanding, the flowcharts are organized such that theinitial flowcharts present implementations via an example implementationand thereafter the following flowcharts present alternateimplementations and/or expansions of the initial flowchart(s) as eithersub-component operations or additional component operations building onone or more earlier-presented flowcharts. Those having skill in the artwill appreciate that the style of presentation utilized herein (e.g.,beginning with a presentation of a flowchart(s) presenting an exampleimplementation and thereafter providing additions to and/or furtherdetails in subsequent flowcharts) generally allows for a rapid and easyunderstanding of the various process implementations. In addition, thoseskilled in the art will further appreciate that the style ofpresentation used herein also lends itself well to modular and/orobject-oriented program design paradigms.

In any event, after a start operation, the operational flow 500 of FIG.5 may move to a first directive receiving operation 502 for receivingone or more first directives that direct a transportation vehicle unitto transport a first end user. For instance, and as illustration, thedirective receiving module 202* of the transport computing device 10* ofFIG. 2A or 2B (e.g., the directive receiving module 202′ of FIG. 2A orthe directive receiving module 202″ of FIG. 2B) receiving one or morefirst directives that direct (e.g., instructs) a transportation vehicleunit 20 to transport a first end user 12 a. As will be further describedbelow, the one or more first directives that are received may providevarious information including pickup location (e.g., rendezvouslocation) for rendezvousing with the first end user, the destination(e.g., destination location) for the first end user, carpoolingpreferences, and so forth. In various implementations, the one or morefirst directives may be received from a network entity (e.g., areal-time carpooling coordinating system 15 or a real-time carpoolingmanagement system 16 of FIG. 1) or may entered by a human driver (whomay have picked-up a street fare—e.g., the first end user 12 a)associated with the transportation vehicle unit 20.

Operational flow 500 may also include a second directive receivingoperation 504 for receiving, while the transportation vehicle unit is enroute to or is transporting the first end user, one or more seconddirectives that direct the transportation vehicle unit to transport asecond end user while transporting the first end user, thetransportation vehicle unit having been determined to be able toaccommodate transport of the second end user while transporting thefirst end user. For instance, the directive receiving module 202* (e.g.,the directive receiving module 202′ of FIG. 2A or the directivereceiving module 202″ of FIG. 2B) of the transport computing device 10*of FIG. 2A or 2B receiving, while the transportation vehicle unit 20 isen route to rendezvousing with the first end user 12 a at a first enduser rendezvous location or is transporting the first end user 12 a, oneor more second directives that direct (e.g., instruct) thetransportation vehicle unit 20 to transport a second end user 12 b whiletransporting the first end user 12 a, the transportation vehicle unit 20having been determined by, for example, the real-time carpoolingmanagement system 16 of FIG. 1, to be able to accommodate transport ofthe second end user 12 b while the transportation vehicle unit 20 istransporting the first end user 12 a. Note that for purposes of thisdescription the phrase “en route to or is transporting the first enduser” may also include the point or span in time in which thetransportation vehicle unit 20 a has reached a rendezvous location forrendezvousing with the first end user 12 a and is waiting for the firstend user 12 a to reach the rendezvous location.

As further illustrated in FIG. 5, operational flow 500 may furtherinclude a non-conflict verifying operation 506 for verifying thatcompliance with the one or more second directives will not conflict withone or more obligations to transport the first end user by thetransportation vehicle unit. For instance, the non-conflict confirmingmodule 204* (e.g., the non-conflict confirming module 204′ of FIG. 2A orthe non-conflict confirming module 204″ of FIG. 2B) of the transportcomputing device 10* of FIG. 2A or 2B verifying or confirming thatcompliance with the one or more second directives to transport thesecond end user 12 b by the transportation vehicle unit 20 will notconflict with one or more obligations to transport the first end user 12a by the transportation vehicle unit 20. For example, verifying orconfirming that the transportation vehicle unit 20 can still fulfill anobligation to transport the first end user 12 a to a first end userdestination location without significant delay even if thetransportation vehicle unit 20 transports the second end user 12 b whiletransporting the first end user 12 a.

As will be described below, the first directive receiving operation 502,the second directive receiving operation 504, and the non-conflictverifying operation 506 may be executed in a variety of different waysin various alternative implementations. FIGS. 6A, 6B, 6C, and 6D, forexample, illustrate at least some of the alternative ways that the firstdirective receiving operation 502 of FIG. 5 may be executed in variousalternative implementations. In some cases, for example, the firstdirective receiving operation 502 may include an operation 602 forreceiving the one or more first directives electronically via one ormore wireless and/or wired networks as illustrated in FIG. 6A. Forinstance, the directive receiving module 202* of the transport computingdevice 10* (e.g., the transport computing device 10′ of FIG. 2A or thetransport computing device 10″ of FIG. 2B) receiving the one or morefirst directives electronically via one or more wireless and/or wirednetworks 18 (e.g., cellular data network, WLAN, WAN, MAN (metropolitanarea network), Ethernet, etc.). In some cases, the directive receivingmodule 202* may control a network interface 240 in order toelectronically receive the one or more package delivery directives.

In various implementations, the first directive receiving operation 502may include an operation 603 for receiving one or more first directivesthat identify a rendezvous location for rendezvousing with the first enduser and/or that identifies a first end user destination location forthe first end user. For instance, the directive receiving module 202* ofthe transport computing device 10* of FIG. 2A or 2B receiving one ormore first directives that identify a rendezvous location (e.g., thecurrent GPS location of the first end user 12 a when the firstdirectives are received) for the transportation vehicle unit torendezvous with the first end user and/or that identifies a first enduser destination location for the first end user.

In the same or alternative implementations, the first directivereceiving operation 502 may alternatively or additionally include anoperation 604 for receiving the one or more first directives includingreceiving one or more carpooling preferences associated with transportof the first end user by the transportation vehicle unit. For instance,the directive receiving module 202* including the carpooling preferencereceiving module 302 (see FIG. 3A) of the transport computing device 10*of FIG. 2A or 2B receiving the one or more first directives includingreceiving one or more carpooling preferences associated with transportof the first end user 12 a by the transportation vehicle unit 20. Forexample, the one or more carpooling preferences may indicate that thetransportation vehicle unit 20 will be permitted to transport other endusers (not associated with the first end user 12 a) while transportingthe first end user 12 a if transport of the end users will not cause asignificant delay (e.g., more than 15 minutes delay) in the first enduser 12 a reaching his or her destination.

As further illustrated in FIG. 6A, in various implementations, operation604 may include an operation 605 for receiving the one or morecarpooling preferences from an end user device associated with the firstend user. For instance, the carpooling preference receiving module 302of the transport computing device 10* of FIG. 2A or 2B receiving the oneor more carpooling preferences from an end user device 14 (e.g., amobile device such as a Smartphone or tablet computer, a laptopcomputer, and so forth) associated with the first end user 12 a.

In the same or alternative implementations, operation 604 mayalternatively or additionally include an operation 606 for receiving oneor more carpooling preferences that permit transport, by thetransportation vehicle unit, of one or more other end users notaffiliated with the first end user while the transportation vehicle unitis transporting the first end user only if one or more specifiedconditions can be or have already been realized. For instance, thecarpooling preference receiving module 302 of the transport computingdevice 10* of FIG. 2A or 2B receiving one or more carpooling preferencesthat permit transport, by the transportation vehicle unit 20, of one ormore other end users not affiliated with the first end user 12 a whilethe transportation vehicle unit 20 is transporting the first end user 12a only if one or more specified conditions can be or have already beenrealized (e.g., transport of the other end users will not causesignificant delays for transporting the first end user 12 a to his/herdestination or the transportation vehicle unit 20 has sufficientpassenger space to accommodate the other end users).

In some implementations, operation 606 may actually involve an operation607 for receiving one or more carpooling preferences that permittransport, by the transportation vehicle unit, of the one or more otherend users while the transportation vehicle unit is transporting thefirst end user so long as transport of the one or more other users bythe transportation vehicle unit does not cause a delay in transportingthe first end user to a first end user destination location that isgreater than a predefined amount of maximum permitted delay. Forinstance, the carpooling preference receiving module 302 of thetransport computing device 10* of FIG. 2A or 2B receiving one or morecarpooling preferences that permit transport, by the transportationvehicle unit 20, of the one or more other end users while thetransportation vehicle unit 20 is transporting the first end user 12 aas long as transport of the one or more other users by thetransportation vehicle unit 20 does not cause a delay in transportingthe first end user to a first end user destination location that isgreater than a predefined amount of maximum permitted delay (e.g.,maximum allowable delay of 25 minutes or less). In some cases, a delaythat may be caused by transporting other end users may be calculated by,for example, first estimating the amount of time it would take totransport the first end user 12 a to a destination location when thetransportation vehicle unit 20 is not transporting other end users thenestimating the amount of time it would take to transport the first enduser 12 a to the destination location when the transportation vehicleunit 20 is transporting other end users, and then determining thedifference between the two estimated times in order to determine theestimated time delay that would result as a result of the transportationvehicle unit 20 transporting other end users while transporting thefirst end user 12 a.

In some cases, operation 607 may further involve an operation 608 forreceiving one or more carpooling preferences that permit transport, bythe transportation vehicle unit, of the one or more other end userswhile the transportation vehicle unit is transporting the first end userso long as transport of the one or more other users by thetransportation vehicle unit does not cause a delay in transporting thefirst end user to a first end user destination location that is greaterthan a 20 minutes of maximum permitted delay. For instance, thecarpooling preference receiving module 302 of the transport computingdevice 10* of FIG. 2A or 2B receiving one or more carpooling preferencesthat permit (e.g., as permitted by the logic of the transport computingdevice 10* when the logic abides with the one or more carpoolingpreferences) transport, by the transportation vehicle unit 20, of theone or more other end users while the transportation vehicle unit 20 istransporting the first end user 12 a as long as transport of the one ormore other users by the transportation vehicle unit 20 does not cause adelay in transporting the first end user 12 a to a first end userdestination location that is greater than a 20 minutes of maximumpermitted delay.

Turning to FIG. 6B, in the same or alternative implementations,operation 606 for receiving one or more carpooling preferences thatpermit transport, by the transportation vehicle unit, of one or moreother end users not affiliated with the first end user while thetransportation vehicle unit is transporting the first end user only ifone or more specified conditions can be or have already been realizedmay additionally or alternatively include an operation 609 for receivingone or more carpooling preferences that permit transport, by thetransportation vehicle unit, of the one or more other end users whilethe transportation vehicle unit is transporting the first end user solong as transport of the one or more other end users by thetransportation vehicle unit does not cause the transportation vehicleunit to have a number of end user drop-offs prior to the first end userbeing dropped-off that is greater than a predefined amount of maximumpermitted end user drop-offs permitted before the first end user isdropped-off. For instance, the carpooling preference receiving module302 of the transport computing device 10* of FIG. 2A or 2B receiving oneor more carpooling preferences that permit (e.g., as permitted by thelogic of the transport computing device 10* when the logic complies withthe one or more carpooling preferences) transport, by the transportationvehicle unit 20, of the one or more other end users while thetransportation vehicle unit 20 is transporting the first end user 12 aas long as transport of the one or more other end users by thetransportation vehicle unit 20 does not cause the transportation vehicleunit 20 to have a number of end user drop-offs (e.g., the act or acts ofoff-loading passengers at their destination location(s)) prior to thefirst end user 12 a being dropped-off that is greater than a predefinedamount of maximum permitted end user drop-offs permitted before thefirst end user is dropped-off. For example, if the maximum number ofpermitted end user drop-offs prior to the first end user 12 a is two butthe addition of other end users during transport of the first end user12 a would result in the transportation vehicle unit 20 having three enduser drop-offs prior to the first end user 12 a being dropped-off at thefirst end user's destination location, then the transport of the otherend users by the transportation vehicle unit 20 while transporting thefirst end user 12 a will not be permitted by the logic of the transportcomputing device 10* (e.g., the logic of the transport computing device10* will reject directives to transport the other end users).

In some cases, operation 609 may actually involve an operation 610 forreceiving one or more carpooling preferences that permit transport, bythe transportation vehicle unit, of the one or more other end userswhile the transportation vehicle unit is transporting the first end userso long as transport of the one or more other users by thetransportation vehicle unit does not cause the transportation vehicleunit to have a number of end user drop-offs prior to the first end userbeing dropped-off that is greater than a maximum of three end userdrop-offs permitted before the first end user is dropped-off. Forinstance, the carpooling preference receiving module 302 of thetransport computing device 10* of FIG. 2A or 2B receiving one or morecarpooling preferences that permit (e.g., as permitted by the logic ofthe transport computing device 10* when the logic complies with the oneor more carpooling preferences) transport, by the transportation vehicleunit 20, of the one or more other end users while the transportationvehicle unit 20 is transporting the first end user 12 a as long astransport of the one or more other users by the transportation vehicleunit 20 does not cause the transportation vehicle unit 20 to bescheduled to have a number of end user drop-offs prior to the first enduser 12 a being dropped-off that is greater than a maximum of three enduser drop-offs permitted before the first end user 12 a is dropped-off

In the same or alternative implementations, operation 606 mayadditionally or alternatively include an operation 611 for receiving oneor more carpooling preferences that permit transport, by thetransportation vehicle unit, of the one or more other end users whilethe transportation vehicle unit is transporting the first end user solong as transport of the one or more other users by the transportationvehicle unit does not cause any end user drop-off to occur prior todrop-off of the first end user. For instance, the carpooling preferencereceiving module 302 of the transport computing device 10* of FIG. 2A or2B receiving one or more carpooling preferences that permit (e.g., aspermitted by the logic of the transport computing device 10* when thelogic complies with the one or more carpooling preferences) transport,by the transportation vehicle unit 20, of the one or more other endusers while the transportation vehicle unit 20 is transporting the firstend user 12 a as long as transport of the one or more other users by thetransportation vehicle unit 20 does not cause any end user drop-off(e.g., end user offloading) to occur prior to drop of the first end user12 a.

In the same or alternative implementations, operation 606 mayadditionally or alternatively include an operation 612 for receiving oneor more carpooling preferences that permit transport, by thetransportation vehicle unit, of the one or more other end users whilethe transportation vehicle unit is transporting the first end user, theone or more carpooling preferences defining maximum permitted number ofrendezvous stops permitted for rendezvousing with end users during asingle carpooling trip. For instance, the carpooling preferencereceiving module 302 of the transport computing device 10* of FIG. 2A or2B receiving one or more carpooling preferences that permit (e.g., aspermitted by the logic of the transport computing device 10* when thelogic complies with the one or more carpooling preferences) transport,by the transportation vehicle unit 20, of the one or more other endusers while the transportation vehicle unit 20 is transporting the firstend user 12 a, the one or more carpooling preferences defining maximumpermitted number of rendezvous stops permitted for rendezvousing withend users during a single carpooling trip (e.g., a trip route totransport a group of unaffiliated end users from one or more rendezvouslocations to one or more destination locations).

In the same or alternative implementations, operation 606 mayadditionally or alternatively include an operation 613 for receiving oneor more carpooling preferences that permit transport, by thetransportation vehicle unit, of the one or more other end users whilethe transportation vehicle unit is transporting the first end user, theone or more carpooling preferences defining maximum number of end userdrop-off stops for dropping-off of end users permitted during a singlecarpooling trip. For instance, the carpooling preference receivingmodule 302 of the transport computing device 10* of FIG. 2A or 2Breceiving one or more carpooling preferences that permit (e.g., aspermitted by the logic of the transport computing device 10* when thelogic complies with the one or more carpooling preferences) transport,by the transportation vehicle unit 20, of the one or more other endusers while the transportation vehicle unit 20 is transporting the firstend user 12 a, the one or more carpooling preferences defining maximumnumber of end user drop-off stops permitted for dropping-off of endusers including the first end user 12 a during a single carpooling trip.

Turning now to FIG. 6C, in various implementations, operation 606 mayinclude an operation 614 for receiving one or more carpoolingpreferences that permit transport, by the transportation vehicle unit,of the one or more other end users while the transportation vehicle unitis transporting the first end user, the one or more carpoolingpreferences defining a single rendezvous location for the transportationvehicle unit to rendezvous with all end users including the first enduser to be transported by the transportation vehicle unit. For instance,the carpooling preference receiving module 302 of the transportcomputing device 10* of FIG. 2A or 2B receiving one or more carpoolingpreferences that permit transport, by the transportation vehicle unit20, of the one or more other end users while the transportation vehicleunit 20 is transporting the first end user 12 a, the one or morecarpooling preferences defining a single rendezvous location for thetransportation vehicle unit 20 to rendezvous with all end usersincluding the first end user 12 a to be transported by thetransportation vehicle unit 20 during a single carpooling trip.

In the same or alternative implementations, operation 606 mayalternatively or additionally include an operation 615 for receiving oneor more carpooling preferences that permit transport, by thetransportation vehicle unit, of the one or more other end users whilethe transportation vehicle unit is transporting the first end user, theone or more carpooling preferences defining a single destinationlocation for dropping-off all end users including the first end user tobe transported by the transportation vehicle unit. For instance, thecarpooling preference receiving module 302 of the transport computingdevice 10* of FIG. 2A or 2B receiving one or more carpooling preferencesthat permit transport, by the transportation vehicle unit 20, of the oneor more other end users while the transportation vehicle unit 20 istransporting the first end user 12 a, the one or more carpoolingpreferences defining a single destination location for dropping-off allend users including the first end user 12 a to be transported by thetransportation vehicle unit 20 during a single carpooling trip.

In the same or alternative implementations, operation 606 mayadditionally or alternatively include an operation 616 for receiving oneor more carpooling preferences that permit transport, by thetransportation vehicle unit, of the one or more other end users whilethe transportation vehicle unit is transporting the first end user, theone or more carpooling preferences including a preference that all otherend users to be transported by the transportation vehicle unit while thetransportation vehicle unit is transporting the first end user share atleast one specified common interest. For instance, the carpoolingpreference receiving module 302 of the transport computing device 10* ofFIG. 2A or 2B receiving one or more carpooling preferences that permittransport, by the transportation vehicle unit 20, of the one or moreother end users while the transportation vehicle unit 20 is transportingthe first end user 12 a, the one or more carpooling preferencesincluding a preference that all other end users to be transported by thetransportation vehicle unit 20 while the transportation vehicle unit 20is transporting the first end user 12 a share at least one specifiedcommon interest (e.g., all end users to be transported by thetransportation vehicle unit 20 are fans of the New York Jets).

In the same or alternative implementations, operation 606 mayadditionally or alternatively include an operation 617 for receiving theone or more carpooling preferences via a user interface or via one ormore wireless and/or wired networks. For instance, the carpoolingpreference receiving module 302 of the transport computing device 10* ofFIG. 2A or 2B receiving the one or more carpooling preferences via auser interface 250 (e.g., a keypad or touchscreen) or via one or morewireless and/or wired networks 18 through a network interface 240. Thatis, in some cases, the carpooling preferences may be entered by a humandriver, who may be provided with carpooling preferences from the firstend user 12 a. Alternatively, such carpooling preferences may bereceived wirelessly from a network device such as the realtimecarpooling management system 16 or from a real-time carpoolingcoordinating system 15 of FIG. 1.

Referring now to FIG. 6D, in the same or alternative implementations,the first directive receiving operation 502 may additionally oralternatively include an operation 618 for receiving the one or morefirst directives including receiving transport rate data that indicatesone or more transport rates for the first end user that are based, atleast in part, on the transportation vehicle unit transporting one ormore other end users while transporting the first end user. Forinstance, the carpooling preference receiving module 302 including thetransport rate data receiving module 304 (see FIG. 3A) of the transportcomputing device 10* of FIG. 2A or 2B receiving the one or more firstdirectives including receiving, by the transport rate data receivingmodule 304, transport rate data that indicates one or more transportrates for the first end user 12 a that are based, at least in part, onthe transportation vehicle unit 20 transporting one or more other endusers (e.g., a second end user 12 b) while transporting the first enduser 12 a. Note that in some cases, the one or more transport rates maybe received separately from the one or more first directives.

In some implementations, operation 618 may further include an operation619 for receiving transport rate data that indicates one or moretransport rates for the first end user that are based, at least in part,on the number of other end users that the transportation vehicle unitwill be transporting while transporting the first end user, the otherend users not being affiliated with the first end user. For instance,the transport rate data receiving module 304 of the transport computingdevice 10* of FIG. 2A or 2B receiving transport rate data that indicatesone or more transport rates for the first end user 12 a that are based,at least in part, on the number of other end users that thetransportation vehicle unit 20 will be transporting while transportingthe first end user 12 a, the other end users (e.g., a second end user 12b) not being affiliated with the first end user 12 a.

In some cases, operation 618 may additionally or alternatively includean operation 620 for receiving transport rate data that indicates one ormore transport rates for the first end user that are based, at least inpart, on the number of end user drop-offs scheduled to occur at leastduring transport of the first end user by the transportation vehicleunit. For instance, the transport rate data receiving module 304 of thetransport computing device 10* of FIG. 2A or 2B receiving transport ratedata that indicates one or more transport rates for the first end user12 a that are based, at least in part, on the number of end userdrop-offs scheduled to occur at least during transport of the first enduser 12 a by the transportation vehicle unit 20.

In some implementations, the first directive receiving operation 502 mayinclude an operation 621 for receiving the one or more first directivesincluding receiving image data for one or more facial images of thefirst end user. For instance, the directive receiving module 202*including the image data receiving module 306 (see FIG. 3A) of thetransport computing device 10* of FIG. 2A or 2B receiving the one ormore first directives including receiving, by the image data receivingmodule 306, image data for one or more facial images of the first enduser 12 a. By providing the facial image of the first end user 12 a, ahuman driver may be able to quickly recognize the first end user 12 aparticularly in a crowded venue such as at a stadium exit after afootball game.

Referring back to the second directive receiving operation 504 of FIG.5, the second directive receiving operation 504 similar to the firstdirective receiving operation 502 of FIG. 5 may be executed in a numberof different ways in various alternative embodiments as illustrated, forexample, in FIGS. 7A, 7B, 7C, and 7D. In some cases, for example, thesecond directive receiving operation 504 may actually include anoperation 722 for receiving the one or more second directiveselectronically via one or more wireless and/or wired networks. Forinstance, the directive receiving module 202* of the transport computingdevice 10* of FIG. 2A or 2B receiving the one or more second directiveselectronically using a network interface 240 via one or more wirelessand/or wired networks 18.

In the same or alternative implementation, the second directivereceiving operation 504 may include an operation 723 for receiving,while the transportation vehicle unit is en route to or is transportingthe first end user, the one or more second directives by receiving theone or more second directives when the transportation vehicle unit isspatially moving towards a first end user rendezvous location in orderto rendezvous with the first end user. For instance, the directivereceiving module 202* of the transport computing device 10* of FIG. 2Aor 2B receiving, while the transportation vehicle unit 20 is en route torendezvousing with a first end user 12 a or is transporting the firstend user 12 a, the one or more second directives by receiving the one ormore second directives when the transportation vehicle unit 20 isspatially moving towards a first end user rendezvous location (e.g.,first end user rendezvous location 402 of FIG. 4A) in order torendezvous with the first end user 12 a.

In some cases, operation 723 may actually involve an operation 724 forreceiving the one or more second directives when the transportationvehicle unit is spatially moving towards the first end user rendezvouslocation and is within four miles from the first end user rendezvouslocation. For instance, the directive receiving module 202* of thetransport computing device 10* of FIG. 2A or 2B receiving the one ormore second directives when the transportation vehicle unit 20 isspatially moving towards the first end user rendezvous location and iswithin four miles from reaching the first end user rendezvous locationfor rendezvousing with the first end user 12 a.

In some implementations, the second directive receiving module 504 mayactually include an operation 725 for receiving, while thetransportation vehicle unit is en route to or is transporting the firstend user, the one or more second directives by receiving the one or moresecond directives when the transportation vehicle unit has alreadysecured the first end user. For instance, the directive receiving module202* of the transport computing device 10* of FIG. 2A or 2B receiving,while the transportation vehicle unit 20 is en route to rendezvousingwith a first end user 12 a or is transporting the first end user 12 a,the one or more second directives by receiving the one or more seconddirectives when the transportation vehicle unit 20 has already securedthe first end user 12 a.

In some implementations, the second directive receiving module 504 mayinclude an operation 726 for receiving, while the transportation vehicleunit is en route to or is transporting the first end user, the one ormore second directives by receiving the one or more second directiveswhen the transportation vehicle unit is within 15 minutes or less fromrendezvousing with the first end user. For instance, the directivereceiving module 202* of the transport computing device 10* of FIG. 2Aor 2B receiving, while the transportation vehicle unit 20 is en route torendezvousing with a first end user 12 a or is transporting the firstend user 12 a, the one or more second directives by receiving the one ormore second directives when the transportation vehicle unit 20 is within15 minutes or less from rendezvousing with the first end user 12 a.

In some implementations, the second directive receiving operation 504may include an operation 727 for receiving the one or more seconddirectives by receiving one or more second directives that identify asecond end user rendezvous location for rendezvousing with the secondend user. For instance, the directive receiving module 202* of thetransport computing device 10* of FIG. 2A or 2B receiving the one ormore second directives by receiving one or more second directives thatidentify a second end user rendezvous location (e.g., GPS dataindicating current location of the second end user 12 b) forrendezvousing (by the transportation vehicle unit 20) with the secondend user 12 b.

In some implementations, the second directive receiving operation 504may include an operation 728 for receiving the one or more seconddirectives by receiving one or more second directives that identify asecond end user destination location for dropping-off the second enduser as illustrated in FIG. 7B. For instance, the directive receivingmodule 202* of the transport computing device 10* of FIG. 2A or 2Breceiving the one or more second directives by receiving one or moresecond directives that identify a second end user destination locationfor dropping-off (e.g., the act of offloading one or more passengers orend users) the second end user 12 b.

In some implementations, the second directive receiving operation 504may include an operation 729 for receiving the one or more seconddirectives by receiving one or more second directives that identify thenumber of passengers and/or luggage to be transported with the secondend user. For instance, the directive receiving module 202* of thetransport computing device 10* of FIG. 2A or 2B receiving the one ormore second directives by receiving one or more second directives thatidentify the number of passengers and/or luggage to be transported withthe second end user 12 b.

In some implementations, the second directive receiving operation 504may include an operation 730 for receiving the one or more seconddirectives that direct the transportation vehicle unit to transport thesecond end user by receiving one or more second directives that directthe transportation vehicle unit to drop-off the first end user and thesecond end user in a particular order. For instance, the directivereceiving module 202* of the transport computing device 10* of FIG. 2Aor 2B receiving the one or more second directives that direct thetransportation vehicle unit 20 to transport the second end user 12 b byreceiving one or more second directives that direct (e.g., instruct) thetransportation vehicle unit 20 to drop-off the first end user 12 a andthe second end user 12 b in a particular order.

In some implementations, the second directive receiving operation 504may include an operation 731 for receiving the one or more seconddirectives that direct the transportation vehicle unit to transport thesecond end user by receiving one or more second directives that identifya route for dropping-off the first end user and the second end user. Forinstance, the directive receiving module 202* of the transport computingdevice 10* of FIG. 2A or 2B receiving the one or more second directivesthat direct the transportation vehicle unit 20 to transport the secondend user 12 b by receiving one or more second directives that identify aroute (e.g., street-by-street/turn-by-turn route) for dropping-off thefirst end user 12 a and the second end user 12 b.

In various implementations, the second directive receiving operation 504may include an operation 732 for receiving the one or more seconddirectives that direct the transportation vehicle unit to transport thesecond end user including receiving one or more carpooling preferencesof the second end user. For instance, the directive receiving module202* including the carpooling preference receiving module 302 (see FIG.3A) of the transport computing device 10* of FIG. 2A or 2B receiving theone or more second directives that direct the transportation vehicleunit 20 to transport the second end user 12 b including receiving one ormore carpooling preferences of the second end user 12 b. In variousimplementations, the one or more carpooling preferences may be receivedseparately from the one or more second directives. In some cases, theone or more carpooling preferences may be provided by the second enduser 12 b, while in other cases, the one or more carpooling preferencesmay be provided by a third party such as by a ridesharing company thatis administrating the carpooling services.

In some implementations, operation 732 may further include an operation733 for receiving one or more carpooling preferences of the second enduser that indicates maximum number of end user drop-offs permitted priorto the second end user being dropped-off. For instance, the carpoolingpreference receiving module 302 of the transport computing device 10* ofFIG. 2A or 2B receiving one or more carpooling preferences of the secondend user 12 b that indicates maximum number of end user drop-offspermitted prior to the second end user 12 b being dropped-off.

As In the same or alternative implementations, operation 732 mayadditionally or alternatively include an operation 734 for receiving oneor more carpooling preferences of the second end user that indicatemaximum amount of time delay permitted in transporting the second enduser to a second end user destination location and as a result of thetransportation vehicle unit transporting one or more other end usersincluding the first end user. For instance, the carpooling preferencereceiving module 302 of the transport computing device 10* of FIG. 2A or2B receiving one or more carpooling preferences of the second end user12 b that indicate maximum amount of time delay permitted intransporting the second end user 12 b to a second end user destinationlocation and as a result of the transportation vehicle unit 20transporting one or more other end users including the first end user 12a.

In the same or alternative implementations, the second directivereceiving operation 504 may include an operation 735 for receiving theone or more second directives that direct the transportation vehicleunit to transport the second end user including receiving transport ratedata that indicates a transport rate for transporting the second enduser by the transportation vehicle unit. For instance, the directivereceiving module 202* including the transport rate data receiving module304 (see FIG. 3A) of the transport computing device 10* of FIG. 2A or 2Breceiving the one or more second directives that direct thetransportation vehicle unit 20 to transport the second end user 12 bincluding receiving, by the transport rate data receiving module 304,transport rate data that indicates a transport rate (e.g., a fare orfee) for transporting the second end user 12 b by the transportationvehicle unit 20.

As further illustrated in FIG. 7C, in various implementations, operation735 may actually include one or more additional operations including, insome cases, an operation 736 for receiving the transport rate dataseparately from reception of the one or more second directives. Forinstance, the transport rate data receiving module 304 of the transportcomputing device 10* of FIG. 2A or 2B receiving (e.g., receivingelectronically) the transport rate data separately from reception of theone or more second directives.

In the same or alternative implementations, operation 735 mayadditionally or alternatively include an operation 737 for receivingtransport rate data that indicates a discounted transport rate for thesecond end user, the discount transport rate for the second end userbeing based, at least in part, on the total number of end users beingtransported by the transportation vehicle unit while transporting thesecond end user. For instance, the transport rate data receiving module304 of the transport computing device 10* of FIG. 2A or 2B receivingtransport rate data that indicates a discounted transport rate for thesecond end user 12 b, the discount transport rate for the second enduser 12 b being based, at least in part, on the total number of endusers (including the first end user 12 a) being transported by thetransportation vehicle unit 20 while transporting the second end user 12b.

In some implementations, operation 735 may include an operation 738 forreceiving transport rate data that indicates a discounted transport ratefor the second end user, the discount transport rate for the second enduser being based, at least in part, on the number of planned end userdrop-offs to be made by the transportation vehicle unit prior to thesecond end user being dropped-off at a second end user destinationlocation. For instance, the transport rate data receiving module 304 ofthe transport computing device 10* of FIG. 2A or 2B receiving transportrate data that indicates a discounted transport rate for the second enduser 12 b, the discount transport rate for the second end user 12 bbeing based, at least in part, on the number of planned end userdrop-offs to be made by the transportation vehicle unit 20 prior to thesecond end user 12 b being dropped-off at a second end user destinationlocation.

In some implementations, operation 735 may include an operation 739 forreceiving transport rate data that indicates a premium transport ratefor the second end user, the premium transport rate for the second enduser being a higher transport rate than a transport rate for the firstend user for being transported by the transportation vehicle unit. Forinstance, the transport rate data receiving module 304 of the transportcomputing device 10* of FIG. 2A or 2B receiving transport rate data thatindicates a premium transport rate for the second end user 12 b, thepremium transport rate for the second end user 12 b being a highertransport rate than a transport rate for the first end user 12 a forbeing transported by the transportation vehicle unit 20. For example, ifthe first end user 12 a is being charged 12 dollars then the second enduser 12 b may be charged in the amount greater than 12 dollars such as16 dollars. This may be done in some cases to provide an incentive forthe first end user 12 a to permit other end users (e.g., the second enduser 12 b) to join the first end user 12 a in being transported by thetransportation vehicle unit 20. That is, by making the second end user12 b pay a larger portion of the total fare (and having the first enduser 12 a pay a smaller share of the total fare), the first end user 12a may be provided an incentive to accept other end users.

In some implementations, operation 735 may include an operation 740 forreceiving transport rate data that indicates a discounted transport ratefor the first end user, the discounted transport rate being as a resultof the second end user being assigned to be transported by thetransportation vehicle unit, the discounted transport rate for the firstend user being less than a transport rate for the first end user thatwas provided prior to assignment of the second end user to thetransportation vehicle unit. For instance, the transport rate datareceiving module 304 of the transport computing device 10* of FIG. 2A or2B receiving transport rate data that indicates a discounted transportrate for the first end user 12 a, the discounted transport rate being asa result of or based on the second end user 12 b being assigned to betransported by the transportation vehicle unit 20, the discountedtransport rate for the first end user 12 a being less than a transportrate for the first end user 12 a that was provided prior to assignmentof the second end user 12 b to the transportation vehicle unit 20.

In some implementations, operation 735 may include an operation 741 forreceiving transport rate data that indicates a discounted transport ratefor the first end user, the discounted transport rate being as a resultof the transportation vehicle unit making an additional passengerdrop-off prior to the first end user being dropped-off at a first enduser destination location and as a result of the second end user beingassigned to be transported by the transportation vehicle unit. Forinstance, the transport rate data receiving module 304 of the transportcomputing device 10* of FIG. 2A or 2B receiving transport rate data thatindicates a discounted transport rate for the first end user 12 a, thediscounted transport rate being as a result of the transportationvehicle unit 20 making an additional passenger drop-off prior to thefirst end user 12 a being dropped-off at a first end user destinationlocation and as a result of the second end user 12 b being assigned tobe transported by the transportation vehicle unit 20.

In various implementations, the second directive receiving operation 504may include an operation 742 for receiving the one or more seconddirectives that direct the transportation vehicle unit to transport asecond end user, the transportation vehicle unit having been remotelydetermined across one or more wireless and/or wired networks to be ableto accommodate transport of the second end user while transporting thefirst end user as illustrated in FIG. 7D. For instance, the directivereceiving module 202* of the transport computing device 10* of FIG. 2Aor 2B receiving the one or more second directives that direct thetransportation vehicle unit 20 to transport a second end user 12 b, thetransportation vehicle unit 20 having been remotely determined (e.g.,determined by the real-time carpooling management system 16 of FIG. 1)across one or more wireless and/or wired networks 18 to be able toaccommodate (e.g., having sufficient cabin space and/or is located inthe proximate vicinity of the second end user 12 b) transport of thesecond end user 12 b while transporting the first end user 12 a.

In the same or alternative implementations, the second directivereceiving operation 504 may include an operation 743 for receiving theone or more second directives that direct the transportation vehicleunit to transport a second end user, the transportation vehicle unithaving been determined, when the one or more second directives arereceived, to be in the proximate vicinity of a second end userrendezvous location for rendezvousing with the second end user. Forinstance, the directive receiving module 202* of the transport computingdevice 10* of FIG. 2A or 2B receiving the one or more second directivesthat direct the transportation vehicle unit 20 to transport a second enduser 12 b, the transportation vehicle unit 20 having been determined(e.g., by the real-time carpooling management system 16), when the oneor more second directives are received by the transport computing device10*, to be in the proximate vicinity (e.g., within 5 miles) of a secondend user rendezvous location (e.g., current location of the second enduser 12 b) for rendezvousing with the second end user 12 b. Note that invarious embodiments the phrase “when the one or more second directivesare received by the transport computing device 10*,” as used herein, maybe in reference to a time span that includes at least when the one ormore second directives are transmitted by the real-time carpoolingmanagement system 16 to when the transport computing device 10* receivesthe one or more second directives.

In the same or alternative implementations, the second directivereceiving operation 504 may include an operation 744 for receiving theone or more second directives that direct the transportation vehicleunit to transport a second end user, the transportation vehicle unithaving been determined, when the one or more second directives arereceived, to have sufficient available space to accommodate the secondend user. For instance, the directive receiving module 202* of thetransport computing device 10* of FIG. 2A or 2B receiving the one ormore second directives that direct the transportation vehicle unit 20 totransport a second end user 12 b, the transportation vehicle unit 20having been determined (e.g., by the real-time carpooling managementsystem 16), when the one or more second directives are received by thetransport computing device 10*, to have sufficient available space toaccommodate the second end user 12 b.

In the same or alternative implementations, the second directivereceiving operation 504 may include an operation 745 for receiving theone or more second directives that direct the transportation vehicleunit to transport a second end user, the transportation vehicle unithaving been determined, when the one or more second directives arereceived, scheduled for traveling near to a second end user destinationlocation of the second end user when transporting one or more other endusers including the first end user. For instance, the directivereceiving module 202* of the transport computing device 10* of FIG. 2Aor 2B receiving the one or more second directives that direct thetransportation vehicle unit 20 to transport a second end user 12 b, thetransportation vehicle unit 20 having been determined (e.g., by thereal-time carpooling management system 16), when the one or more seconddirectives are received by the transport computing device 10*, scheduledfor traveling near to (e.g., within 3 miles) a second end userdestination location of the second end user 12 b when transporting oneor more other end users including the first end user 12 a.

In the same or alternative implementations, the second directivereceiving operation 504 may include an operation 746 for receiving theone or more second directives that direct the transportation vehicleunit to transport a second end user, the transportation vehicle unithaving been determined, when the one or more second directives arereceived, to be able to accommodate transport of the second end userwhile transporting the first end user without violating one or morecarpooling preferences. For instance, the directive receiving module202* of the transport computing device 10* of FIG. 2A or 2B receivingthe one or more second directives that direct the transportation vehicleunit to transport a second end user 12 b, the transportation vehicleunit 20 having been determined (e.g., by the real-time carpoolingmanagement system 16), when the one or more second directives arereceived, to be able to accommodate transport of the second end user 12b while transporting the first end user 12 a without violating one ormore carpooling preferences (e.g., carpooling preferences of the firstend user 12 a, the second end user 12 b, and/or a thirdparty—preferences related to permitted number of end user drop-offs,permitted delays in transporting each of the end users, etc.).

Referring back to the non-conflict verifying operation 506 of FIG. 5,the non-conflict verifying operation 506, similar to the first directivereceiving operation 502 and the second directive receiving operation 504of FIG. 5, may be executed in a number of different ways in variousalternative embodiments as illustrated, for example, in FIGS. 8A, 8B,8C, 8D, 8E, 8F, and 8G. In some cases, for example, the non-conflictverifying operation 506 may actually include an operation 847 forverifying that compliance with the one or more second directives willnot conflict with one or more obligations to transport the first enduser by the transportation vehicle unit, the one or more obligationsbeing based, at least in part, on the received one or more firstdirectives. For instance, the non-conflict confirming module 204* of thetransport computing device 10* of FIG. 2A or 2B verifying or confirmingthat compliance with the one or more second directives will not conflictwith (e.g., will not violate) one or more obligations to transport thefirst end user 12 a by the transportation vehicle unit 20, the one ormore obligations being based, at least in part, on the received one ormore first directives.

In the same or alternative implementations, the non-conflict verifyingoperation 506 may include an operation 848 for verifying that compliancewith the one or more second directives will not conflict with one ormore obligations to transport the first end user by the transportationvehicle unit, the one or more obligations defining one or moreconditional directives that permit the transportation vehicle unit totransport one or more other end users while the transportation vehicleunit is transporting the first end user only if one or more specifiedconditions can be or have already been realized as illustrated in FIGS.8A, 8B, 8C, and 8D. For instance, the non-conflict confirming module204* of the transport computing device 10* of FIG. 2A or 2B verifying(e.g., confirming) verifying that compliance with the one or more seconddirectives will not conflict with one or more obligations to transportthe first end user 12 a by the transportation vehicle unit 20, the oneor more obligations defining one or more conditional directives thatpermit the transportation vehicle unit 20 to transport one or more otherend users (who are not affiliated with the first end user 12 a), such asthe second end user 12 b, while the transportation vehicle unit 20 istransporting the first end user 12 a only if one or more specifiedconditions can be or have already been realized (e.g., the one or morespecified conditions can be met by transporting the one or more otherend users and while transporting the first end user 12 a or the one ormore specified conditions have already been met). In some cases, thelogic of the transport computing device 10* may, upon determining thatthe one or more specified have been or can be met, permit the transportof a second end user 12 b by the transportation vehicle unit 20 bysimply presenting (e.g., presenting to a human driver or a roboticdriver) the one or more second directives.

As further illustrated in FIGS. 8A, 8B, 8C, and 8D, in variousalternative implementations, operation 848 may include one or moreadditional operations including, in some cases, an operation 849 forverifying that compliance with the one or more second directives willnot conflict with one or more obligations to transport the first enduser by the transportation vehicle unit, the one or more obligationsdefining one or more conditional directives that permit transport, bythe transportation vehicle unit, of the second end user while thetransportation vehicle unit is transporting the first end user only iftransport of the one or more other end users by the transportationvehicle unit does not cause a delay in transporting the first end userto a first end user destination location that is greater than apredefined amount of maximum permitted delay as illustrated in FIG. 8A.For instance, the non-conflict confirming module 204* of the transportcomputing device 10* of FIG. 2A or 2B verifying (e.g., confirming) thatcompliance with the one or more second directives will not conflict withone or more obligations to transport the first end user 12 a by thetransportation vehicle unit 20, the one or more obligations defining oneor more conditional directives that permit transport, by thetransportation vehicle unit 20, of the one or more other end users whilethe transportation vehicle unit 20 is transporting the first end user 12a only if transport of the second end user (e.g., the second end user 12b) by the transportation vehicle unit 20 does not cause a delay intransporting the first end user 12 a to a first end user destinationlocation that is greater than a predefined amount of maximum permitteddelay (e.g., 15 minutes of maximum delay).

In some implementations, operation 849 may further include an operation850 for verifying that compliance with the one or more second directiveswill not conflict with one or more obligations to transport the firstend user by the transportation vehicle unit, the one or more obligationsdefining one or more conditional directives that permit transport, bythe transportation vehicle unit, of the second end user while thetransportation vehicle unit is transporting the first end user only iftransport of the one or more other end users by the transportationvehicle unit does not cause a delay in transporting the first end userto a first end user destination location that is greater than a 20minutes of maximum permitted delay. For instance, the non-conflictconfirming module 204* of the transport computing device 10* of FIG. 2Aor 2B verifying (e.g., confirming) that compliance with the one or moresecond directives will not conflict with one or more obligations totransport the first end user 12 a by the transportation vehicle unit 20,the one or more obligations defining one or more conditional directivesthat permit transport, by the transportation vehicle unit 20, of thesecond end user 12 b while the transportation vehicle unit 20 istransporting the first end user 12 a only if transport of the one ormore other end users (e.g., second end user 12 b) by the transportationvehicle unit 20 does not cause a delay in transporting the first enduser 12 a to a first end user destination location that is greater thana 20 minutes of maximum permitted delay.

In the same or alternative implementations, operation 848 may include anoperation 851 for verifying that compliance with the one or more seconddirectives will not conflict with one or more obligations to transportthe first end user by the transportation vehicle unit, the one or moreobligations defining one or more conditional directives that permittransport, by the transportation vehicle unit, of the second end userwhile the transportation vehicle unit is transporting the first end useronly if transport of the one or more other end users by thetransportation vehicle unit does not cause the transportation vehicleunit to have a number of end user drop-offs prior to the first end userbeing dropped-off that is greater than a predefined amount of maximumpermitted end user drop-offs permitted before the first end user isdropped-off as illustrated in FIG. 8B. For instance, the non-conflictconfirming module 204* of the transport computing device 10* of FIG. 2Aor 2B verifying or confirming that compliance with the one or moresecond directives will not conflict with one or more obligations totransport the first end user 12 a by the transportation vehicle unit 20,the one or more obligations defining one or more conditional directivesthat permit transport, by the transportation vehicle unit 20, of thesecond end user 12 b while the transportation vehicle unit 20 istransporting the first end user 12 a only if transport of the one ormore other end users (e.g., the second end user 12 b) by thetransportation vehicle unit 20 does not cause the transportation vehicleunit 20 to have a number of end user drop-offs prior to the first enduser 12 a being dropped-off that is greater than a predefined amount ofmaximum permitted end user drop-offs (e.g., four drop-offs or passengeroffloading stops) permitted before the first end user 12 a isdropped-off.

In some cases, operation 851 may further include an operation 852 forverifying that compliance with the one or more second directives willnot conflict with one or more obligations to transport the first enduser by the transportation vehicle unit, the one or more obligationsdefining one or more conditional directives that permit transport, bythe transportation vehicle unit, of the one or more other end userswhile the transportation vehicle unit is transporting the first end useronly if transport of the one or more other end users by thetransportation vehicle unit does not cause the transportation vehicleunit to have a number of end user drop-offs prior to the first end userbeing dropped-off that is greater than a maximum of three end userdrop-offs permitted before the first end user is dropped-off. Forinstance, the non-conflict confirming module 204* of the transportcomputing device 10* of FIG. 2A or 2B verifying (e.g., confirming) thatcompliance with the one or more second directives will not conflict withone or more obligations to transport the first end user 12 a by thetransportation vehicle unit 20, the one or more obligations defining oneor more conditional directives that permit transport, by thetransportation vehicle unit 20, of the second end user 12 b while thetransportation vehicle unit 20 is transporting the first end user 12 aonly if transport of the one or more other end users (e.g., second enduser 12 b) by the transportation vehicle unit 20 does not cause thetransportation vehicle unit 20 to have a number of end user drop-offsprior to the first end user 12 a being dropped-off that is greater thana maximum of three end user drop-offs (e.g., passenger offloading stops)permitted before the first end user 12 a is dropped-off.

In the same or alternative implementations, operation 848 may include anoperation 853 for verifying that compliance with the one or more seconddirectives will not conflict with one or more obligations to transportthe first end user by the transportation vehicle unit, the one or moreobligations defining one or more conditional directives that permittransport, by the transportation vehicle unit, of the one or more otherend users while the transportation vehicle unit is transporting thefirst end user only if transport of the one or more other end users bythe transportation vehicle unit does not cause any end user drop-off tooccur prior to drop of the first end user being dropped-off that isgreater than a maximum of three end user drop-offs permitted before thefirst end user is dropped-off as illustrated in FIG. 8C. For instance,the non-conflict confirming module 204* of the transport computingdevice 10* of FIG. 2A or 2B verifying (e.g., confirming) that compliancewith the one or more second directives will not conflict with one ormore obligations to transport the first end user 12 a by thetransportation vehicle unit 20, the one or more obligations defining oneor more conditional directives that permit transport, by thetransportation vehicle unit 20, of the one or more other end users(e.g., the second end user 12 b) while the transportation vehicle unit20 is transporting the first end user 12 a only if transport of the oneor more other end users (e.g., the second end user 12 b) by thetransportation vehicle unit 20 does not cause the transportation vehicleunit to have a number of end user drop-offs prior first end user 12 abeing dropped-off that is greater than a maximum of three end userdrop-offs permitted before the first end user 12 a is dropped-off.

In the same or alternative implementations, operation 848 may include anoperation 854 for verifying that compliance with the one or more seconddirectives will not conflict with one or more obligations to transportthe first end user by the transportation vehicle unit, the one or moreobligations defining one or more conditional directives that permittransport, by the transportation vehicle unit, of the one or more otherend users while the transportation vehicle unit is transporting thefirst end user only if transport of the one or more other end users bythe transportation vehicle unit does not result in the transportationvehicle unit having a total number of rendezvous stops for rendezvousingwith end users including the first end user and the one or more otherend users that exceed a maximum permitted number of rendezvous stopspermitted for rendezvousing with the end users during a singlecarpooling trip. For instance, the non-conflict confirming module 204*of the transport computing device 10* of FIG. 2A or 2B verifying (e.g.,confirming) that compliance with the one or more second directives willnot conflict with one or more obligations to transport the first enduser 12 a by the transportation vehicle unit 20, the one or moreobligations defining one or more conditional directives that permittransport, by the transportation vehicle unit 20, of the one or moreother end users (e.g., the second end user 12 b) while thetransportation vehicle unit 20 is transporting the first end user 12 aonly if transport of the one or more other end users (e.g., the secondend user 12 b) by the transportation vehicle unit 20 does not result inthe transportation vehicle unit 20 having a total number of rendezvousstops for rendezvousing with end users including the first end user 12 aand the one or more other end users that exceed a maximum permittednumber of rendezvous stops permitted for rendezvousing with end usersduring a single carpooling trip.

In the same or alternative implementations, operation 848 may include anoperation 855 for verifying that compliance with the one or more seconddirectives will not conflict with one or more obligations to transportthe first end user by the transportation vehicle unit, the one or moreobligations defining one or more conditional directives that permittransport, by the transportation vehicle unit, of the one or more otherend users while the transportation vehicle unit is transporting thefirst end user only if transport of the one or more other end users bythe transportation vehicle unit does not result in the transportationvehicle unit having a total number of end user drop-off stops thatexceeds a maximum permitted number of end user drop-off stops permittedduring a single carpooling trip. For instance, the non-conflictconfirming module 204* of the transport computing device 10* of FIG. 2Aor 2B verifying (e.g., confirming) that compliance with the one or moresecond directives will not conflict with one or more obligations totransport the first end user 12 a by the transportation vehicle unit 20,the one or more obligations defining one or more conditional directivesthat permit transport, by the transportation vehicle unit 20, of the oneor more other end users (e.g., the second end user 12 b) while thetransportation vehicle unit 20 is transporting the first end user 12 aonly if transport of the one or more other end users (e.g., the secondend user 12 b) by the transportation vehicle unit 20 does not result inthe transportation vehicle unit 20 having a total number of end userdrop-off stops that exceeds a maximum permitted number of end userdrop-off stops permitted during a single carpooling trip.

In the same or alternative implementations, operation 848 may include anoperation 856 for verifying that compliance with the one or more seconddirectives will not conflict with one or more obligations to transportthe first end user by the transportation vehicle unit, the one or moreobligations defining one or more conditional directives that permittransport, by the transportation vehicle unit, of the one or more otherend users while the transportation vehicle unit is transporting thefirst end user only if the one or more other end users will berendezvousing with the transportation vehicle unit at a rendezvouslocation that is the designating location for the first end user torendezvousing with the transportation vehicle unit as illustrated inFIG. 8D. For instance, the non-conflict confirming module 204* of thetransport computing device 10* of FIG. 2A or 2B verifying (e.g.,confirming) that compliance with the one or more second directives willnot conflict with one or more obligations to transport the first enduser 12 a by the transportation vehicle unit 20, the one or moreobligations defining one or more conditional directives that permittransport, by the transportation vehicle unit 20, of the one or moreother end users (e.g., the second end user 12 b) while thetransportation vehicle unit 20 is transporting the first end user 12 aonly if the one or more other end users (e.g., the second end user 12 b)will be rendezvousing with the transportation vehicle unit 20 at arendezvous location that is the designating location for the first enduser 12 a to rendezvousing with the transportation vehicle unit 20.

In the same or alternative implementations, operation 848 may include anoperation 857 for verifying that compliance with the one or more seconddirectives will not conflict with one or more obligations to transportthe first end user by the transportation vehicle unit, the one or moreobligations defining one or more conditional directives that permittransport, by the transportation vehicle unit, of the one or more otherend users while the transportation vehicle unit is transporting thefirst end user only if the one or more other end users are to betransported to a destination location that is the same as thedestination location for the first end user. For instance, thenon-conflict confirming module 204* of the transport computing device10* of FIG. 2A or 2B verifying (e.g., confirming) that compliance withthe one or more second directives will not conflict with one or moreobligations to transport the first end user 12 a by the transportationvehicle unit 20, the one or more obligations defining one or moreconditional directives that permit transport, by the transportationvehicle unit 20, of the one or more other end users (e.g., the secondend user 12 b) while the transportation vehicle unit 20 is transportingthe first end user 12 a only if the one or more other end users (e.g.,the second end user 12 b) are to be transported to a destinationlocation that is the same as the destination location for the first enduser 12 a.

In the same or alternative implementations, operation 848 may include anoperation 858 for verifying that compliance with the one or more seconddirectives will not conflict with one or more obligations to transportthe first end user by the transportation vehicle unit, the one or moreobligations defining one or more conditional directives that permittransport, by the transportation vehicle unit, of the one or more otherend users while the transportation vehicle unit is transporting thefirst end user only if the one or more other end users have at least onespecified common interest with the first end user. For instance, thenon-conflict confirming module 204* of the transport computing device10* of FIG. 2A or 2B verifying (e.g., confirming) that compliance withthe one or more second directives will not conflict with one or moreobligations to transport the first end user 12 a by the transportationvehicle unit 20, the one or more obligations defining one or moreconditional directives that permit transport, by the transportationvehicle unit 20, of the one or more other end users (e.g., the secondend user 12 b) while the transportation vehicle unit 20 is transportingthe first end user 12 a only if the one or more other end users (e.g.,the second end user 12 b) have at least one specified common interest(e.g., New York Yankees) with the first end user 12 a.

Referring now to FIG. 8E, in various implementations, the non-conflictverifying operation 506 may include an operation 859 for verifying thatthe transportation vehicle unit is in the proximate vicinity of a secondend user rendezvous location for rendezvousing with the second end user.For instance, the rendezvous location proximity confirming module 308(see FIG. 3B) of the transport computing device 10* of FIG. 2A or 2Bverifying (e.g., confirming) that the transportation vehicle unit 20 isin the proximate vicinity (e.g., within 5 miles) of a second end userrendezvous location for rendezvousing with the second end user 12 b.

In the same or alternative implementations, the non-conflict verifyingoperation 506 may include an operation 860 for verifying that thetransportation vehicle unit has sufficient available space toaccommodate the second end user. For instance, the spatial availabilityconfirming module 310 (see FIG. 3B) of the transport computing device10* of FIG. 2A or 2B verifying (e.g., confirming) that thetransportation vehicle unit 20 has sufficient available passenger space(as well as luggage space) to accommodate the second end user 12 b.

In the same or alternative implementations, the non-conflict verifyingoperation 506 may include an operation 861 for verifying that thetransportation vehicle unit is scheduled for traveling near to a secondend user destination location of the second end user when transportingone or more other end users including the first end user. For instance,the spatial availability confirming module 310 (see FIG. 3B) of thetransport computing device 10* of FIG. 2A or 2B verifying (e.g.,confirming) that the transportation vehicle unit 20 is scheduled fortraveling near to (e.g., in the vicinity—within 3 miles) a second enduser destination location of the second end user 12 b when transportingone or more other end users including the first end user 12 a.

In the same or alternative implementations, the non-conflict verifyingoperation 506 may include an operation 862 for verifying that compliancewith the one or more second directives will not conflict with the one ormore obligations to transport the first end user by the transportationvehicle unit by verifying that transport of the second end user by thetransportation vehicle unit while transporting the first end user willnot violate one or more carpooling preferences of the first end user.For instance, the non-conflict confirming module 204* including thecarpooling preference non-conflict confirming module 314 (see FIG. 3B)of the transport computing device 10* of FIG. 2A or 2B verifying (e.g.,confirming) that compliance with the one or more second directives willnot conflict with the one or more obligations to transport the first enduser 12 a by the transportation vehicle unit 20 by having the carpoolingpreference non-conflict confirming module 314 verify or confirm thattransport of the second end user 12 b by the transportation vehicle unit20 while transporting the first end user 12 a will not violate one ormore carpooling preferences (e.g., no significant delay, such as a 15minute delay, in being transported with other end users, beingtransported with other end users who are New York Jets fans, preferencefor being dropped-off first, and so forth) of the first end user 12 a.

In the same or alternative implementations, the non-conflict verifyingoperation 506 may include an operation 863 for verifying that compliancewith the one or more second directives will not conflict with the one ormore obligations to transport the first end user by the transportationvehicle unit by verifying that transport of the second end user by thetransportation vehicle unit while transporting the first end user willnot violate one or more carpooling preferences of the second end user.For instance, the non-conflict confirming module 204* including thecarpooling preference non-conflict confirming module 314 of thetransport computing device 10* of FIG. 2A or 2B verifying (confirming)that compliance with the one or more second directives will not conflictwith the one or more obligations to transport the first end user 12 a bythe transportation vehicle unit 20 by having the carpooling preferencenon-conflict confirming module 314 verify or confirm that transport ofthe second end user 12 b by the transportation vehicle unit 20 whiletransporting the first end user 12 a will not violate one or morecarpooling preferences of the second end user 12 b.

Turning now to FIG. 8F, in various implementations, the non-conflictverifying operation 506 may include an operation 864 for determining atransport rate for the first end user that is based, at least in part,on the transportation vehicle unit transporting one or more other endusers including the second end user while transporting the first enduser. For instance, the transport rate ascertaining module 316 (see FIG.3B) of the transport computing device 10* of FIG. 2A or 2B determiningor ascertaining a transport rate for the first end user 12 a (e.g., afee for transporting the first end user 12 a) that is based, at least inpart, on the transportation vehicle unit 20 transporting one or moreother end users including the second end user 12 b while transportingthe first end user 12 a. In some cases, the determined transport ratemay be used to verify a transport rate for the first end user 12 a thatwas provided by a network entity (e.g., the real-time carpoolingmanagement system 16 of FIG. 1).

As further illustrated in FIG. 8F, in various implementations, operation864 may involve an operation 865 for determining a transport rate forthe first end user that is based, at least in part, on the number ofother end users that the transportation vehicle unit will betransporting while transporting the first end user, the other end usersnot being affiliated with the first end user. For instance, thetransport rate ascertaining module 316 of the transport computing device10* of FIG. 2A or 2B determining (e.g., ascertaining) a transport ratefor the first end user 12 a that is based, at least in part, on thenumber of other end users including the second end user 12 b that thetransportation vehicle unit 12 b will be transporting while transportingthe first end user 12 a, the other end users not being affiliated with(e.g., having no business and/or personal relationship with) the firstend user 12 a.

In some implementations, operation 864 may involve an operation 866 fordetermining a transport rate for the first end user that is based, atleast in part, on the number of end user drop-offs scheduled to occur atleast during transport of the first end user by the transportationvehicle unit. For instance, the transport rate ascertaining module 316of the transport computing device 10* of FIG. 2A or 2B determining(e.g., ascertaining) a transport rate for the first end user 12 a thatis based, at least in part, on the number of end user drop-offsscheduled to occur at least during transport of the first end user 12 aby the transportation vehicle unit 20.

In some implementations, operation 864 may involve an operation 867 fordetermining a discounted transport rate for the first end user, thediscounted transport rate being as a result of the second end user beingassigned to be transported by the transportation vehicle unit, thediscounted transport rate for the first end user being less than atransport rate for the first end user that was provided prior toassignment of the second end user to the transportation vehicle unit.For instance, the transport rate ascertaining module 316 of thetransport computing device 10* of FIG. 2A or 2B determining (e.g.,ascertaining) a discounted transport rate for the first end user 12 a,the discounted transport rate being as a result of the second end user12 b being assigned to be transported by the transportation vehicle unit20, the discounted transport rate for the first end user 12 a being lessthan a transport rate for the first end user 12 a that was providedprior to assignment of the second end user 12 b to the transportationvehicle unit 20, the discounted transport rate being as a result of thesecond end user 12 b being assigned to be transported by thetransportation vehicle unit 20 while transporting the first end user 12a.

In some implementations, operation 864 may involve an operation 868 fordetermining a discounted transport rate for the first end user, thediscounted transport rate being as a result of the transportationvehicle unit making an additional passenger drop-off prior to the firstend user being dropped-off at a first end user destination location andas a result of the second end user being assigned to be transported bythe transportation vehicle unit. For instance, the transport rateascertaining module 316 of the transport computing device 10* of FIG. 2Aor 2B determining (e.g., ascertaining) a discounted transport rate forthe first end user 12 a, the discounted transport rate being as a resultof the transportation vehicle unit 20 making an additional passengerdrop-off prior to the first end user 12 a being dropped-off (e.g.,offloaded) at a first end user destination location and as a result ofthe second end user 12 b being assigned to be transported by thetransportation vehicle unit 20.

Referring now to FIG. 8G, in various implementations, the non-conflictverifying operation 506 may include an operation 869 for determining atransport rate for the second end user that is based, at least in part,on the transportation vehicle unit transporting one or more other endusers including the first end user while transporting the second enduser. For instance, the transport rate ascertaining module 316 of thetransport computing device 10* of FIG. 2A or 2B determining orascertaining a transport rate for the second end user 12 b (e.g., a farefor transporting the second end user 12 b) that is based, at least inpart, on the transportation vehicle unit 20 transporting one or moreother end users including the first end user 12 a while transporting thesecond end user 12 b. In some cases, the determined transport rate maybe used to verify a transport rate for the second end user 12 b that wasprovided by a network entity (e.g., the real-time carpooling managementsystem 16 of FIG. 1).

As further illustrated in FIG. 8G, in some implementations, operation869 may involve an operation 870 for determining a discounted transportrate for the second end user, the discount transport rate for the secondend user being based, at least in part, on the total number of end usersbeing transported by the transportation vehicle unit while transportingthe second end user. For instance, the transport rate ascertainingmodule 316 of the transport computing device 10* of FIG. 2A or 2Bdetermining (e.g., ascertaining) a discounted transport rate for thesecond end user 12 b, the discount transport rate for the second enduser 12 b being based, at least in part, on the total number of endusers (including the first end user 12 a) being transported by thetransportation vehicle unit 20 while transporting the second end user 12b.

In some implementations, operation 869 may involve an operation 871 fordetermining a discounted transport rate for the second end user, thediscount transport rate for the second end user being based, at least inpart, on the number of planned end user drop-offs to be made by thetransportation vehicle unit prior to the second end user being droppedoff at a second end user destination location. For instance, thetransport rate ascertaining module 316 of the transport computing device10* of FIG. 2A or 2B determining (e.g., ascertaining) a discountedtransport rate for the second end user 12 b, the discount transport ratefor the second end user 12 b being based, at least in part, on thenumber of planned end user drop-offs to be made by the transportationvehicle unit 20 prior to the second end user 12 b being dropped off at asecond end user destination location and during the carpooling trip thatresults in the second end user 12 b and the first end user 12 a beingtransported to their destination locations.

In some implementations, operation 869 may involve an operation 872 fordetermining a premium transport rate for the second end user, thepremium transport rate for the second end user being a higher transportrate than a transport rate for the first end user for being transportedby the transportation vehicle unit. For instance, the transport rateascertaining module 316 of the transport computing device 10* of FIG. 2Aor 2B determining (e.g., ascertaining) a premium transport rate for thesecond end user 12 b, the premium transport rate for the second end user12 b being a higher transport rate than a transport rate for the firstend user 12 a for being transported by the transportation vehicle unit20.

Turning now to FIG. 9 illustrating another operational flow 900.Operational flow 900 includes certain operations that mirror theoperations included in operational flow 500 of FIG. 5. These operationsinclude a first directive receiving operation 902, a second directivereceiving operation 904, and a non-conflict verifying operation 906 thatcorresponds to and mirrors the first directive receiving operation 502,the second directive receiving operation 504, and the non-conflictverifying operation 506, respectively, of FIG. 5.

In addition, operational flow 900 further include a confirmationtransmitting operation 908 for transmitting one or more confirmationsthat the one or more second directives have been accepted for executionby the transportation vehicle unit. For instance, the confirmationtransmitting module 206* of the transport computing device 10* of FIG.2A or 2B transmitting electronically, via one or more wireless and/orwired networks 18, one or more confirmations that the one or more seconddirectives have been accepted for execution by the transportationvehicle unit 20. In some cases the one or more confirmations may betransmitted to a real-time carpooling management system 16.

As further illustrated in FIG. 9, in some implementations, theconfirmation transmitting operation 908 may actually involve anoperation 910 for transmitting the one or more confirmations in responseto verification that compliance with the one or more second directiveswill not conflict with one or more obligations to transport the firstend user by the transportation vehicle unit. For instance, theconfirmation transmitting module 206* of the transport computing device10* of FIG. 2A or 2B transmitting the one or more confirmations inresponse to verification that compliance with the one or more seconddirectives will not conflict with one or more obligations to transportthe first end user 12 a by the transportation vehicle unit 20.

Turning now to FIG. 10 illustrating another operational flow 1000.Operational flow 1000 includes certain operations that mirror theoperations included in operational flow 500 of FIG. 5. These operationsinclude a first directive receiving operation 1002, a second directivereceiving operation 1004, and a non-conflict verifying operation 1006that corresponds to and mirrors the first directive receiving operation502, the second directive receiving operation 504, and the non-conflictverifying operation 506, respectively, of FIG. 5.

In addition, operation 1000 further includes an instructive directivepresenting operation 1008 for presenting, in response to verificationthat compliance with the one or more second directives will not conflictwith one or more obligations to transport the first end user by thetransportation vehicle unit, one or more instructive directives thatdirect the transportation vehicle unit to transport the second end user.For instance, the instructive directive presenting module 208* of thetransport computing device 10* of FIG. 2A or 2B presenting, in responseto verification that compliance with the one or more second directiveswill not conflict with one or more obligations to transport the firstend user 12 a by the transportation vehicle unit 20, one or moreinstructive directives that direct the transportation vehicle unit 20 totransport the second end user 12 b.

As further illustrated in FIG. 11, the instructive directive presentingoperation 1008 may be implemented in a variety of different ways invarious alternative implementations. For example, in someimplementations, the instructive directive presenting operation 1008 mayinvolve an operation 1176 for presenting visually and/or audibly the oneor more instructive directives via user interface. For instance, thevisual/audible instructive directive presenting module 320 (see FIG. 3C)of the transport computing device 10* of FIG. 2A or 2B presentingvisually and/or audibly the one or more instructive directives via userinterface 250 (e.g., a display screen and/or one or more speakers)

In the same or alternative implementations, the instructive directivepresenting operation 1008 may involve an operation 1177 for presentingelectronically the one or more instructive directives to a navigationsystem of a robotic driver system of the transportation vehicle unit.For instance, the electronic instructive directive presenting module 322(see FIG. 3C) of the transport computing device 10* of FIG. 2A or 2Bpresenting electronically the one or more instructive directives to anavigation system 452 of a robotic driver system 450 of thetransportation vehicle unit 20.

In the same or alternative implementations, the instructive directivepresenting operation 1008 may involve an operation 1178 for presentingthe one or more instructive directives by presenting one or moreinstructive directives that identify a rendezvous location forrendezvousing with the second end user and/or that identify a second enduser destination location for the second end user. For instance, theinstructive directive presenting module 208* of the transport computingdevice 10* of FIG. 2A or 2B presenting the one or more instructivedirectives by presenting one or more instructive directives thatidentify a rendezvous location for rendezvousing with the second enduser 12 b and/or that identify a second end user destination locationfor the second end user 12 b.

In the same or alternative implementations, the instructive directivepresenting operation 1008 may involve an operation 1179 for presentingthe one or more instructive directives by presenting one or moreinstructive directives that indicate the order in which the first enduser and the second end user are to be dropped-off. For instance, theinstructive directive presenting module 208* of the transport computingdevice 10* of FIG. 2A or 2B presenting the one or more instructivedirectives by presenting one or more instructive directives thatindicate the order in which the first end user 12 a and the second enduser 12 b are to be dropped-off. In some cases, the one or moreinstructive directives may provide a specific route for dropping-off(e.g., offloading) the first end user 12 a and the second end user 12 b.

In the same or alternative implementations, the instructive directivepresenting operation 1008 may involve an operation 1180 for presentingthe one or more instructive directives by presenting one or moreinstructive directives that indicate one or more transport rates for thefirst end user and/or the second end user. For instance, the instructivedirective presenting module 208* of the transport computing device 10*of FIG. 2A or 2B presenting the one or more instructive directives bypresenting one or more instructive directives that indicate one or moretransport rates (e.g., transport fares or fees) for the first end user12 a and/or the second end user 12 b.

While particular aspects of the present subject matter described hereinhave been shown and described, it will be apparent to those skilled inthe art that, based upon the teachings herein, changes and modificationsmay be made without departing from the subject matter described hereinand its broader aspects and, therefore, the appended claims are toencompass within their scope all such changes and modifications as arewithin the true spirit and scope of the subject matter described herein.It will be understood by those within the art that, in general, termsused herein, and especially in the appended claims (e.g., bodies of theappended claims) are generally intended as “open” terms (e.g., the term“including” should be interpreted as “including but not limited to,” theterm “having” should be interpreted as “having at least,” the term“includes” should be interpreted as “includes but is not limited to,”etc.).

It will be further understood by those within the art that if a specificnumber of an introduced claim recitation is intended, such an intentwill be explicitly recited in the claim, and in the absence of suchrecitation no such intent is present. For example, as an aid tounderstanding, the following appended claims may contain usage of theintroductory phrases “at least one” and “one or more” to introduce claimrecitations. However, the use of such phrases should not be construed toimply that the introduction of a claim recitation by the indefinitearticles “a” or “an” limits any particular claim containing suchintroduced claim recitation to claims containing only one suchrecitation, even when the same claim includes the introductory phrases“one or more” or “at least one” and indefinite articles such as “a” or“an” (e.g., “a” and/or “an” should typically be interpreted to mean “atleast one” or “one or more”); the same holds true for the use ofdefinite articles used to introduce claim recitations. In addition, evenif a specific number of an introduced claim recitation is explicitlyrecited, those skilled in the art will recognize that such recitationshould typically be interpreted to mean at least the recited number(e.g., the bare recitation of “two recitations,” without othermodifiers, typically means at least two recitations, or two or morerecitations).

Furthermore, in those instances where a convention analogous to “atleast one of A, B, and C, etc.” is used, in general such a constructionis intended in the sense one having skill in the art would understandthe convention (e.g., “a system having at least one of A, B, and C”would include but not be limited to systems that have A alone, B alone,C alone, A and B together, A and C together, B and C together, and/or A,B, and C together, etc.). In those instances where a conventionanalogous to “at least one of A, B, or C, etc.” is used, in general sucha construction is intended in the sense one having skill in the artwould understand the convention (e.g., “a system having at least one ofA, B, or C” would include but not be limited to systems that have Aalone, B alone, C alone, A and B together, A and C together, B and Ctogether, and/or A, B, and C together, etc.). It will be furtherunderstood by those within the art that typically a disjunctive wordand/or phrase presenting two or more alternative terms, whether in thedescription, claims, or drawings, should be understood to contemplatethe possibilities of including one of the terms, either of the terms, orboth terms unless context dictates otherwise. For example, the phrase “Aor B” will be typically understood to include the possibilities of “A”or “B” or “A and B.”

With respect to the appended claims, those skilled in the art willappreciate that recited operations therein may generally be performed inany order. Also, although various operational flows are presented in asequence(s), it should be understood that the various operations may beperformed in other orders than those which are illustrated, or may beperformed concurrently. Examples of such alternate orderings may includeoverlapping, interleaved, interrupted, reordered, incremental,preparatory, supplemental, simultaneous, reverse, or other variantorderings, unless context dictates otherwise. Furthermore, terms like“responsive to,” “related to,” or other past-tense adjectives aregenerally not intended to exclude such variants, unless context dictatesotherwise.

This application may make reference to one or more trademarks, e.g., aword, letter, symbol, or device adopted by one manufacturer or merchantand used to identify and/or distinguish his or her product from those ofothers. Trademark names used herein are set forth in such language thatmakes clear their identity, that distinguishes them from commondescriptive nouns, that have fixed and definite meanings, or, in many ifnot all cases, are accompanied by other specific identification usingterms not covered by trademark. In addition, trademark names used hereinhave meanings that are well-known and defined in the literature, or donot refer to products or compounds for which knowledge of one or moretrade secrets is required in order to divine their meaning. Alltrademarks referenced in this application are the property of theirrespective owners, and the appearance of one or more trademarks in thisapplication does not diminish or otherwise adversely affect the validityof the one or more trademarks. All trademarks, registered orunregistered, that appear in this application are assumed to include aproper trademark symbol, e.g., the circle R or bracketed capitalization(e.g., [trademark name]), even when such trademark symbol does notexplicitly appear next to the trademark. To the extent a trademark isused in a descriptive manner to refer to a product or process, thattrademark should be interpreted to represent the corresponding productor process as of the date of the filing of this patent application.

Throughout this application, the terms “in an embodiment,” ‘in oneembodiment,” “in some embodiments,” “in several embodiments,” “in atleast one embodiment,” “in various embodiments,” and the like, may beused. Each of these terms, and all such similar terms should beconstrued as “in at least one embodiment, and possibly but notnecessarily all embodiments,” unless explicitly stated otherwise.Specifically, unless explicitly stated otherwise, the intent of phraseslike these is to provide non-exclusive and non-limiting examples ofimplementations of the invention. The mere statement that one, some, ormay embodiments include one or more things or have one or more features,does not imply that all embodiments include one or more things or haveone or more features, but also does not imply that such embodiments mustexist. It is a mere indicator of an example and should not beinterpreted otherwise, unless explicitly stated as such.

Those skilled in the art will appreciate that the foregoing specificexemplary processes and/or devices and/or technologies arerepresentative of more general processes and/or devices and/ortechnologies taught elsewhere herein, such as in the claims filedherewith and/or elsewhere in the present application.

What is claimed is:
 1. A system, comprising: circuitry for receiving oneor more directives that direct a transportation vehicle unit to a firstlocation, the transportation vehicle unit traveling toward a secondlocation and having been determined to be able to travel to the firstlocation while the transportation vehicle unit is traveling toward thesecond location; and circuitry for confirming that compliance with theone or more directives will not conflict with one or more obligations totravel to the second location by the transportation vehicle unit.
 2. Thesystem of claim 1, wherein the circuitry for receiving one or moredirectives that direct a transportation vehicle unit to a firstlocation, the transportation vehicle unit traveling toward a secondlocation and having been determined to be able to travel to the firstlocation while the transportation vehicle unit is traveling toward thesecond location comprises: circuitry for receiving the one or moredirectives when the transportation vehicle unit is within a thresholdtime period from reaching the second location.
 3. The system of claim 1,wherein the circuitry for receiving one or more directives that direct atransportation vehicle unit to a first location, the transportationvehicle unit traveling toward a second location and having beendetermined to be able to travel to the first location while thetransportation vehicle unit is traveling toward the second locationcomprises: circuitry for receiving transport rate data that indicates atransport rate for traveling to the first location by the transportationvehicle unit.
 4. The system of claim 1, wherein the circuitry forreceiving one or more directives that direct a transportation vehicleunit to a first location, the transportation vehicle unit travelingtoward a second location and having been determined to be able to travelto the first location while the transportation vehicle unit is travelingtoward the second location comprises: circuitry for receiving transportrate data that indicates a premium transport rate for traveling to thefirst location that is higher than a transport rate for traveling to thesecond location.
 5. The system of claim 1, wherein the one or moreobligations define one or more conditional directives that permit thetransportation vehicle unit to travel to the first location while thetransportation vehicle unit is traveling toward the second location onlyif traveling to the first location does not cause a delay in travelingto the second location that is greater than a predefined amount ofmaximum permitted delay.
 6. The system of claim 1, wherein the one ormore obligations define one or more conditional directives that permitthe transportation vehicle unit to travel to the first location whilethe transportation vehicle unit is traveling toward the second locationonly if traveling to the first location does not cause a delay intraveling to the second location that is greater than a 20 minutes ofmaximum permitted delay.
 7. The system of claim 1, wherein the circuitryfor confirming that compliance with the one or more directives will notconflict with one or more obligations to travel to the second locationby the transportation vehicle unit comprises: circuitry for confirmingthat the transportation vehicle unit is in the proximate vicinity of thefirst location.
 8. The system of claim 1, wherein the circuitry forconfirming that compliance with the one or more directives will notconflict with one or more obligations to travel to the second locationby the transportation vehicle unit comprises: circuitry for confirmingthat the transportation vehicle unit is scheduled for traveling within athreshold distance to the first location when traveling to the secondlocation.
 9. A system, comprising: circuitry configured for receivingone or more identities of a transportation vehicle unit, thetransportation vehicle unit assigned for traveling to a destination, andat least one estimated time of arrival of the transportation vehicleunit for traveling to the destination; circuitry configured forproviding, via at least one display of at least one electronic device,one or more indications at least partially based on the one or moreidentities of the transportation vehicle unit and on the at least oneestimated time of arrival of the transportation vehicle unit fortraveling to the destination, and further configured for updating the atleast one display of the electronic device with one or more updatedindications of identities of the transportation vehicle unit or one ormore updated estimated times of arrival of the transportation vehicleunit.
 10. The system of claim 9, wherein the circuitry configured forreceiving one or more identities of a transportation vehicle unit, thetransportation vehicle unit assigned for traveling to a destination, andat least one estimated time of arrival of the transportation vehicleunit for traveling to the destination comprises: circuitry configuredfor receiving at least one indication of one or more of make, model,license plate number, or driver name of the at least one transportationvehicle unit.
 11. The system of claim 9, wherein the circuitryconfigured for receiving one or more identities of a transportationvehicle unit, the transportation vehicle unit assigned for traveling toa destination, and at least one estimated time of arrival of thetransportation vehicle unit for traveling to the destination comprises:circuitry configured for receiving one or more identities of atransportation vehicle unit assigned in response to a transmittedrequest for the traveling of the transportation vehicle unit to adestination.
 12. The system of claim 11, wherein the circuitryconfigured for receiving one or more identities of a transportationvehicle unit assigned in response to a transmitted request for thetraveling of the transportation vehicle unit to a destination comprises:circuitry configured for receiving, by a smartwatch, one or moreidentities of a transportation vehicle unit assigned in response to atransmitted request for the traveling of the transportation vehicle unitto a destination, the request transmitted by a smartphone.
 13. Thesystem of claim 12, wherein the circuitry configured for receiving, by asmartwatch, one or more identities of a transportation vehicle unitassigned in response to a transmitted request for the traveling of thetransportation vehicle unit to a destination, the request transmitted bya smartphone comprises: circuitry configured for receiving, from a firstweb service, the one or more identities of a transportation vehicle unitassigned in response to a transmitted request for the traveling of thetransportation vehicle unit to a destination, the request transmitted toa second web service by the smartphone, the one or more identities ofthe transportation vehicle unit received by the first web service fromthe second web service and relayed to the smartwatch.
 14. The system ofclaim 13, wherein the circuitry configured for receiving, from a firstweb service, the one or more identities of a transportation vehicle unitassigned in response to a transmitted request for the traveling of thetransportation vehicle unit to a destination, the request transmitted toa second web service by the smartphone, the one or more identities ofthe transportation vehicle unit received by the first web service fromthe second web service and relayed to the smartwatch comprises:circuitry configured for receiving the one or more identities of atransportation vehicle unit at the smartwatch from the first web servicesubsequent to transmission by the smartphone of the request to a packagedelivery service as the second web service.
 15. The system of claim 9,wherein the circuitry configured for receiving one or more identities ofa transportation vehicle unit, the transportation vehicle unit assignedfor traveling to a destination, and at least one estimated time ofarrival of the transportation vehicle unit for traveling to thedestination comprises: circuitry configured for receiving the one ormore identities of the transportation vehicle unit and the at least oneestimated time of arrival of the transportation vehicle unit from afirst web service subsequent to the first web service receiving one ormore login credentials associated with a package delivery service andrequesting one or more transportation vehicle unit status updatesassociated with the one or more login credentials from the packagedelivery service.
 16. A system, comprising: circuitry configured forascertaining, at least partially based on at least one hardware-basedposition sensor of at least one electronic device, at least onedirection and at least one distance associated with the transportationvehicle unit relative to a rendezvous location; and circuitry configuredfor providing, via the at least one display of the at least oneelectronic device, at least one indication of the at least one positionof the transportation vehicle unit relative to a rendezvous location,and further configured for updating the at least one display of theelectronic device with one or more updated indication of the at leastone position of the transportation vehicle unit.
 17. The system of claim16, wherein the circuitry configured for ascertaining, at leastpartially based on at least one hardware-based position sensor of the atleast one electronic device, at least one direction and at least onedistance associated with the transportation vehicle unit relative to arendezvous location comprises: circuitry configured for ascertaining, atleast partially based on at least one GPS sensor of at least onesmartwatch, at least one direction and at least one distance associatedwith the transportation vehicle unit relative to a rendezvous location.18. The system of claim 16, wherein the circuitry configured forascertaining, at least partially based on at least one hardware-basedposition sensor of at least one electronic device, at least onedirection and at least one distance associated with the transportationvehicle unit relative to a rendezvous location comprises: circuitryconfigured for ascertaining, at least partially based on at least onehardware-based position sensor of the at least one electronic device, atleast one location of the transportation vehicle unit in real-time withat least one of car-length or footstep granularity.
 19. The system ofclaim 16, wherein the circuitry configured for providing, via the atleast one display of the at least one electronic device, at least oneindication of the at least one position of the transportation vehicleunit relative to a rendezvous location comprises: circuitry configuredfor causing at least one display of at least one smartwatch to output atleast one of make, model, license plate number, or driver name of the atleast one transportation vehicle unit.
 20. The system of claim 16,further comprising: circuitry configured for providing, via the at leastone display of the at least one electronic device, an estimate of anamount of time to the rendezvous location destination from a currentlocation of the transportation vehicle unit.